How to Validate and Operate a Self-Hosted AI Deployment

A self-hosted deployment is finished when it passes explicit checks and someone owns its routine. Containers that start are only the beginning. The self-hosting docs place a checklist on each side of the first bring-up: seven items before it and five after. This lesson goes through both, then sets out what running the deployment week to week involves.

Before the first bring-up: seven checks

Work through the pre-deploy checklist from the infrastructure requirements. Each item is either a decision or a test you can mark green:

1. Host or cluster provisioned. Compute, memory and storage are sized to the package’s own requirements.
2. Container runtime installed and healthy. Its info command returns without errors.
3. Outbound path to the registry open. Either to the package registry or, for an air-gapped site, to your internal mirror.
4. Database plan decided. The bundled container for a pilot, managed PostgreSQL for production.
5. TLS and ingress plan decided. Reverse proxy, certificate source and hostname.
6. Secrets storage decided. An environment file for a pilot, a secrets manager for production.
7. Observability plan decided. Where logs and metrics will go.

When all seven are green, the environment is ready. The earlier lessons in this path explain the reasoning behind each item.

What a package brings with it

Every package comes with a suggested way to start it. For most packages at present, you receive three things:

• a Docker Compose file that starts all the services together;
• a small environment file for the few values you set yourself, such as the database password, the hostname and any optional integrations;
• an install guide for that package, available in the portal.

For a first deployment, the docs recommend Docker Compose on a single host as the fastest route. Production setups commonly move to Kubernetes once that first deployment has been validated.

The first bring-up

Run the login command from the portal on the target host, then the pull commands, one after another or in parallel. A typical package is a few gigabytes in total, so the time it takes depends on your connection. If the credentials expire part-way through, mint a fresh set and carry on; there is no penalty for doing so.

Then start the services in the background:

docker compose up -d

Once the services are up and the database has initialised, the frontend answers on the port you set. Validation starts there.

Five checks before you call it done

1. Every service is running. docker compose ps shows each one healthy, and none keeps restarting.
2. The frontend is reachable. Its URL opens the package’s sign-in page in a browser.
3. An administrator can be created. The package’s first-run setup provisions the initial admin account.
4. The logs are clean. Look through the last few minutes of docker compose logs. Some start-up chatter is normal; errors that repeat in a loop are not.
5. A basic flow works. Sign in, carry out one task the package exists for and check the result against what you expected.

If all five pass, the deployment is healthy. Keep a short record of each check: the service list, the sign-in page and the task you ran with its result. It settles later questions about what was working, and when.

Hand-off to your users

Once the checks pass, the work moves from the platform to the people who will use it:

• Add the rest of the team. Accounts live in the package’s own user management, so create one for each person who needs access.
• Connect sources and integrations where the package supports connected apps.
• Agree the operating routine with whoever will run the deployment from now on.

The operating routine

Updates. You decide when a new version arrives. Pull updates on a deliberate cadence, as most operators prefer, or let the package follow an update channel. Bookmark the catalogue page for each package you run. It shows the current version available to you, carries release notes when an update lands and is where you re-pull when you are ready.

Credentials. New hosts and new cluster nodes need to authenticate to the registry, so mint a fresh set for each and let it lapse. The portal’s credential history records who minted each set and when.

Backups. Snapshot the database and every persistent volume. The cadence is yours to set, and daily is a sensible floor for production. Run a restore drill, so you know the snapshots can actually be used.

Logs. Services write JSON logs to standard output and standard error. Any tool that collects container logs can pick them up, such as Fluent Bit or Vector. Set a retention period that meets your policies.

Health and metrics. Each service exposes an HTTP health endpoint that load balancers and orchestrators can poll. Metrics are Prometheus-compatible, and the install guide lists their names and paths.

The account. Watch for trial reminders in the portal and by email. If a trial or subscription ends, running instances continue, but you cannot pull again until it is renewed. That matters most just before an update.

The portal does not monitor your instances, so the deployment is watched only as well as your team sets it up. Connect the routine above to the tools your team already watches.

Write it down as a runbook

Turn the routine into a runbook that names a decision and an owner for each area:

Area	What to decide	Where the docs cover it
Updates	Cadence or channel, and who approves a new version	The package’s catalogue page
Credentials	Who may mint them, and for which hosts	The portal’s credential model
Backups	Snapshot cadence, retention and the next restore drill	Storage requirements
Logs	Collector and retention period	Observability requirements
Health and metrics	Scraper, alert thresholds and who is alerted	The package’s install guide
Account	Trial end date and renewal contact	The portal dashboard

The test of a runbook is whether someone who was not there for the first deployment can keep the service running from it alone. When they can, the deployment belongs to your organisation rather than to one engineer, and it is ready to grow.