TRIP: self-hosted POI mapping and trip planning

Why TRIP uses a map for trip planning

TRIP expands its name to "Tourism and Recreational Interest Points" and addresses a specific planning problem: travel details are often scattered across notes, messages, and lists that do not show where places sit geographically. Its map model gives those points a location, while the trip planner adds day-by-day organization. The intended users are travelers who want to collect places before a journey and turn them into a multi-day plan.

The application also targets groups. The README lists collaboration and sharing with travel companions as core features, so TRIP is not limited to a private list of coordinates. It is designed for a server controlled by the operator, which separates it from a travel notebook that exists only in a browser. The public demo at `itskovacs-trip.netlify.app` offers a way to inspect the interface before deploying the self-hosted container.

That positioning does not make TRIP a replacement for every travel-planning product. The README does not document booking, restaurant reservations, turn-by-turn routing, public place discovery, or automatic itinerary optimization. Its stated scope is narrower: storing and visualizing the user's own points of interest and arranging trip details around them. This narrower design maps closely to collaborative itinerary planning, although it should not be presented as a complete travel operations platform.

How TRIP combines TypeScript and FastAPI

The repository layout separates the application into `src/`, `backend/`, `mcp-server/`, and documentation under `docs/`. The primary language is TypeScript, and the Dockerfile shows how the browser code is compiled. A Node.js 22 build stage copies the package manifests, runs `npm install`, copies the source, and produces the frontend with `npm run build`.

The runtime image uses Python 3.12 slim. It copies the `backend/` directory into `/app`, installs dependencies from `trip/requirements.txt`, and then copies the compiled browser assets into `/app/frontend`. The server is launched through FastAPI. This establishes a split between a TypeScript browser application and a Python API service, but the README does not expose API routes, request schemas, or a database technology.

Persistent storage is mounted at `/app/storage`. The `docker-compose.yml` file maps `./storage` on the host to that container path, so records are not described as residing only in the disposable container layer. The file exposes container port 8000 only on the host's `127.0.0.1` interface, using host port 8080. That default limits direct network exposure. Remote access would require a reverse proxy, tunnel, or host configuration, none of which the README specifies.

Installing TRIP with Docker Compose

Docker Compose is the deployment path the README recommends. Clone the repository, enter its directory, and start the service with the included file. No Compose file changes are required for the documented default.

docker-compose up -d

The service should become available through port 8080 on the host loopback interface. Because the repository file binds `127.0.0.1:8080`, another computer cannot reach the service directly over the network until the operator changes that arrangement or introduces a reverse proxy. The Compose command starts `ghcr.io/itskovacs/trip:1` and uses the bind-mounted `./storage` directory for persistence.

A reader can begin by opening the application, adding points of interest to the map, and creating a multi-day trip with its itinerary. The README confirms maps, POI management, multi-day itineraries, and sharing. It does not document the exact button sequence, required POI fields, initial account screen, or itinerary editing steps. Those details need to be checked in the running application or its linked documentation rather than inferred from the deployment file.

Running TRIP without Docker Compose

For operators who prefer `docker run`, the README supplies a pull-and-run sequence. This path publishes port 8080 without restricting the host address to `127.0.0.1`.

docker pull ghcr.io/itskovacs/trip:1

The image then runs with a persistent storage mount:

docker run -d -p 8080:8000 -v ./storage:/app/storage ghcr.io/itskovacs/trip:1

Host port 8080 maps to container port 8000, and `./storage` is persisted at `/app/storage`. This gives a new self-hosted user a direct deployment without building the repository locally. It also differs from the repository's Compose default in a consequential way: `-p 8080:8000` binds broadly unless Docker or the host applies another restriction, while the Compose file specifies `127.0.0.1:8080:8000`.

The Dockerfile supports a separate source-build path. It uses `node:22` for the frontend and `python:3.12-slim` for the server, but the README does not provide a build-and-run tutorial for that route. The published-image commands are therefore the clearest installation procedure documented for a new deployment.

TRIP configuration, persistence, and backup gaps

The README sends administrators to separate configuration documentation for OIDC authentication and other settings. That separation is sensible because the main README does not enumerate environment variables, accepted values, or default security settings. It leaves an adoption question unanswered from the README alone: whether a fresh installation requires authentication and which identity providers are supported in the current release.

The storage mount is more concrete. Upgrade and backup planning should account for the complete host-side `./storage` directory rather than treating the container as the system of record. The Compose file includes a comment directing users of an older named-volume setup to the `1.5.0` release notes for migration. That reference confirms storage-layout changes have mattered, although the README does not provide backup commands, export formats, or a rollback procedure.

The Compose file uses the floating `ghcr.io/itskovacs/trip:1` tag. Operators should not assume that tag will always resolve to an immutable image. Release `1.50.1` was published on 2026-10-02, but the available deployment instructions do not show how to pin an installation to that version. For a production deployment, validate backups of `./storage`, inspect the migration notes for any older setup, and confirm the chosen image version before replacing a running container.

TRIP compared with a shared travel document

A conventional shared document or spreadsheet can store place names, addresses, notes, and a day-by-day schedule. Its advantage is that collaborators may already know how to edit it. Its weakness is geographic context: a row containing a name and address does not itself provide an interactive overview of nearby points or make the relationship between places and travel days immediately visible.

TRIP takes a different approach. Its primary objects are presented through maps and POI management, while itinerary features organize a trip across multiple days. Collaboration and sharing are part of the stated product model rather than something inferred from exported files. This makes TRIP more purpose-specific for a group assembling a travel plan around saved places.

That focus also creates boundaries. The README does not advertise rich document editing, arbitrary attachments, general-purpose task management, reservation handling, or offline synchronization. A user whose main need is a flexible shared text workspace may prefer a general tool and use TRIP only for geographic planning. A user whose main need is an interactive map and multi-day place organization is the clearer match. The project's value here comes from specializing around places, not from offering every feature found in broader collaboration tools.

TRIP release activity and licensing

The repository is not archived. Its last push was on 2026-10-02. The release list includes `1.50.1` on 2026-10-02, `1.50.0` on 2026-09-27, and `1.49.0` on 2026-08-30. These dates show recent project activity at the time of the recorded repository state. They do not establish a long-term support commitment, a migration guarantee, or an automatic upgrade policy for self-hosted installations.

TRIP uses the MIT license, and the repository includes `license.txt` for the exact terms. This article does not provide legal advice. At the software level, the main operational concern is persistence: replacing container images without a tested copy of the mounted storage directory could put deployment data at risk. The Compose file's reference to migration guidance for the `1.5.0` release also gives operators upgrading older installations a specific place to check before changing the storage mount.

TRIP is appropriate for travelers or small groups that want server control, map-centered planning, and a shared itinerary without the telemetry, tracking, or advertising described in the README. It is a poorer fit when remote internet access, offline use, or a fully documented first-run account flow is mandatory. The published `ghcr.io/itskovacs/trip:1` image, the `127.0.0.1:8080:8000` Compose mapping, and the `/app/storage` persistence boundary are the concrete facts to confirm before production adoption.

Editorial conclusion

TRIP fits travelers who want a self-hosted place for mapping points of interest and organizing multi-day plans, especially when sharing an itinerary with companions matters. It is less suitable for users who need a managed cloud service, a public account system, or documented offline access, since the README does not establish those capabilities. Verify the configuration documentation, authentication requirements, backup procedures for the `storage` directory, and the exact sharing model before adopting it. For a single-container deployment using `ghcr.io/itskovacs/trip:1`, the most concrete starting point is the published image and its `127.0.0.1:8080` port binding.

Frequently asked questions

Official sources

1. itskovacs/trip on GitHub
2. License: MIT
3. Project website
4. README
5. Releases