Platform overview

The applications documented on this site — CustomsHive, TaricHive, and the taric-opendata pipelines — all run on the same small, self-hosted platform. This page describes its shape. It is deliberately general: specifics live in internal documentation.

Three tiers

graph LR
    U[Users] --> E

    subgraph E [Cloud edge]
        P[Reverse proxy<br/>TLS termination]
        I[Identity provider<br/>SSO]
        F[Intrusion detection]
    end

    subgraph S [Storage and services tier]
        A[Application containers]
        D[(Databases and<br/>bulk storage)]
    end

    subgraph G [Compute tier]
        M[GPU inference]
    end

    E --> S
    E --> G
    A --- D

Cloud edge. A small cloud instance is the only machine with a public address. It terminates TLS, runs the single reverse proxy that fronts everything, hosts the identity provider, and screens inbound traffic. Production instances of the applications run here.

Storage and services tier. A self-hosted server carries bulk storage, the databases, the development and QA instances, the build runners, and the logging and backup stacks.

Compute tier. A GPU host serves local language and image models over an OpenAI-compatible API, used for development and for the extraction work that does not go to a hosted service.

The tiers are joined by a private mesh network. Nothing on the internal tiers is directly reachable from the internet — the edge is the only ingress, so every request passes proxy, TLS, and identity checks before reaching an application.

One proxy, one identity provider

There is exactly one reverse proxy for the whole estate, and it lives at the edge. Applications on the internal tiers do not run their own. Instead each container declares its own routing requirements as metadata, an agent on that host collects those declarations, and the central proxy picks them up and begins serving them.

The practical effect is that adding a service is a single-file change with no DNS record, no certificate step, and no proxy reconfiguration. A wildcard certificate and wildcard DNS cover new names automatically.

Authentication is centralised the same way. Applications either speak OpenID Connect to the identity provider directly, or — where an application has no usable auth of its own — the proxy checks each request with the identity provider before it reaches the backend, and passes the resulting identity through as headers. Around twenty applications are protected this way.

The trade-off is honest: this is a deliberate concentration of risk. One proxy and one identity provider mean one certificate story, one access-control story, and one place to look when something breaks — but also a single component whose failure is estate-wide. That trade is made knowingly, and the components involved are the ones held to the strictest update and backup discipline.

Environments

Each application runs in two places. Development and QA instances sit on the internal services tier, close to the data and the build runners; production runs at the edge. Both are built from the same container images, promoted by tag.

Where to next

How we run things covers the conventions — how services are defined, deployed, observed, and backed up.