Skip to content

Quick start

[!CAUTION] This is a controlled-environment quick start. Complete production deployment and security hardening before external exposure.

Install Git, Docker Engine, and Docker Compose. Clone health-tag/data-source-node, then enter the repository root.

Create the six active environment files listed in Environment files. Replace all example placeholders with installation-specific values. Store the TLS certificate at kong-ssl/cert.pem and its private key at kong-ssl/key.pem; restrict access to both files.

Terminal window
docker compose up -d
docker compose ps

All active long-running services should show Up; kong-migration is a migration task and may exit after completion.

The setup scripts call Kong Admin API at localhost:8001, but the current Compose file does not publish that port. Run each script inside the kong container network namespace:

Terminal window
docker compose exec kong bash -s < setup-kong.sh
docker compose exec kong bash -s < setup-healthtag-module.sh

bash -s tells Bash in the running container to read a script from standard input. The < operator reads the script from the host repository and sends it into the container, so the script files do not need to be copied into the image.

The scripts configure different authenticated paths to the same HAPI FHIR server:

Script What it creates
setup-kong.sh Creates the fhir-api service and /fhir-api route with Basic Auth and permissive CORS plugins. It also creates an admin-api service and /admin-api route that proxies Kong’s Admin API, protected by Basic Auth and permissive CORS.
setup-healthtag-module.sh Creates the fhir-api-key-auth service and /fhir-api-key-auth route with the Key Auth plugin for clients that authenticate with an API key.

Both FHIR services forward requests to http://hapi-fhir-jpaserver-start:8080/fhir. The scripts only create Kong services, routes, and plugins; they do not create consumers, Basic Auth credentials, or API keys. Provision those separately before using the protected routes. See Kong routes and authentication for the resulting configuration and verification commands.

The scripts are not idempotent: rerunning them can return conflict responses for existing entities. They also do not stop automatically when an individual curl request fails, so inspect every response rather than assuming the configuration completed successfully.

Terminal window
curl --fail http://localhost:9000/api/health-check
curl --fail http://localhost:8080/fhir/metadata
docker compose ps

The health check returns {} and HAPI returns a FHIR CapabilityStatement. Then complete post-installation verification.