Job compose-app-on-vps-with-tls-and-health-check · revised 11 October 2026
Deploy one Docker Compose app to your VPS with HTTPS and a health check
One Docker Compose app runs on a VPS you own behind HTTPS on your domain, comes back after a reboot, and has a health check you can read, plus the steps to redeploy it.
You might be seeing
- The app runs only because someone started it by hand and nobody can say how to start it again
- A database or cache port is reachable straight from the internet instead of only the web port
- After a server reboot the stack does not come back, or the app starts before its database is ready
No passwords, keys, card details or admin invites needed to start.
What usually happened
A Compose file that works on a developer machine usually misses what a server needs. Containers have no restart policy, the app starts before its database accepts connections, ports are published on every network interface, the certificate is issued once and never renewed, and nothing says whether the app is healthy. Starting it by hand over SSH leaves a server nobody can rebuild from the notes.
Who it’s for: A founder or small team with an app that runs from a Compose file on a laptop or in a hosted platform, but has no repeatable, secured home on a server they control.
Usually starts when: A first production launch, a move off a platform you no longer want, or an app that someone started by hand over SSH and nobody can say how to start again.
The result: One Compose project of up to four services runs on a VPS you own at your domain over HTTPS. It comes back after a server reboot, the app waits for its database to report healthy, only the ports you chose are reachable from outside, and a health URL answers. You receive the files and steps to redeploy and to go back.
Check whether this job fits
Five short checks against your own Compose file. Nothing is sent unless you choose to email your answers.
Checks you can run yourself
List your services and published ports
On the machine where the stack runs today, list the service names and what each container publishes. These commands only read. Do not use the full configuration output, which can print secret values.
docker compose config --services; docker psLook for: The number of services, and any port in the PORTS column shown as 0.0.0.0 or [::] that should not be reachable from the internet, such as a database port.
What you get
- The Compose file, proxy configuration and environment template with no secret values in them
- Output showing a reboot test, the published-port check and the certificate renewal dry run
- A short runbook: start, stop, redeploy, view logs, and go back to the previous version
Included
- One Compose project of up to four services (the app, and optionally a database, a cache and a worker) on one Linux VPS you own
- A production Compose file with a restart policy, health checks, a startup order that waits for a healthy database, ports published only where the plan says, and no application source bind-mounted into containers
- One reverse proxy terminating HTTPS for one domain name, with automatic certificate renewal checked by a dry run; where the name already serves a live site, the checks before the cutover run on a temporary hostname that you point at the VPS
- A health URL, plus a written redeploy procedure, a written certificate route for the cutover and a way back to the previous image tags
Not included
- Buying or creating the VPS account, or paying the provider
- Moving data from another host: a database move with a tested restore is a separate job
- Hardening SSH, the host firewall and updates: that is the Linux baseline job
- More than one server, orchestration across hosts, or a second environment
- Changing application code, including adding a health route the app does not have
- Build and release pipelines, or any promise about uptime
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
After a full reboot of the VPS, every service in the Compose project is running without anyone logging in, and the health URL returns success within five minutes. This is shown on the temporary name before the cutover, and again on the live name after it (on the live name only, for a first launch).
Evidence: Reboot time, the service status listing and the health URL response, taken from a machine outside the server.
curl -sS -o /dev/null -w '%{http_code}\n' https://app.yourbusiness.co.uk/healthBefore the cutover the temporary name serves a valid certificate for that name, and after the cutover the live name serves a valid certificate for the live name; plain http redirects once to https on each. For a first launch only the live name is checked.
Evidence: Certificate details and the redirect check output.
curl -sSIL http://app.yourbusiness.co.uk/ | grep -i -E "^(HTTP|location)"From a machine outside the server, only the ports in the agreed list accept connections; every other port published by a container is closed or unreachable.
Evidence: A table of tested ports with the result for each, including any database or cache port.
The certificate renewal dry run completes without error on the temporary name before the cutover and again on the live name after it (on the live name only, for a first launch), because the staging check also needs the name to point at the VPS, and the handover states how and when renewal runs.
Evidence: Dry-run output and the name of the scheduled renewal job.
sudo certbot renew --dry-runFollowing the written steps on the rehearsal machine redeploys the same stack, and returning one service to its previous image tag restores the earlier version.
Evidence: A transcript of the redeploy and of the return to the previous tag, with the health URL result after each.
Sign-off. You sign off after the reboot test, the outside port check, the certificate checks on the live name and the redeploy rehearsal pass on your server. Payment follows sign-off.
If it fails. If an agreed check fails and we cannot fix it within the scope, you do not pay for this fixed scope and you keep the findings and the files prepared so far. A different server, a larger stack or an application change needs a new written agreement.
When it fits, and when we stop
It fits when
- Your images can be pulled from a registry you control, or built from source you share after agreement
- You administer a Linux VPS running a Debian or Ubuntu release that still receives security updates, with ports 80 and 443 free
- You can point a temporary DNS name, and later the live name, at the VPS, in a window you approve, and tell us when you have
- The app has a web route that returns success only when it is working, or you accept a simple TCP or command check
We stop and tell you if
- The app needs several servers, a managed cluster or hardware such as a GPU
- The only copy of important data would live in a container volume with no restore path agreed
- Ports 80 or 443 cannot be reached from the internet, so the certificate cannot be issued
- The deployment would have to hold your production secrets in clear text in the Compose file or repository
- The live name serves a site that cannot tolerate a short period without a valid certificate at the cutover, and you do not want to copy the existing certificate yourself or pay for the quoted DNS-challenge route
What could go wrong
Before the live name is pointed at the VPS, the old arrangement keeps serving and nothing is lost by stopping the new stack. After it, pointing the DNS name back and stopping the Compose project restores the earlier arrangement; cached DNS answers can send some visitors to the new VPS for a while, so the record lifetime is lowered in advance. Redeploy steps keep the previous image tags so one service can go back to its last tag.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A database or cache port is published on every network interface and is reachable from the internet. | Bind such ports to the loopback address or leave them unpublished, and check every port from outside the server. Docker documents that a published port without a host address is bound on all interfaces. |
| The app starts before its database is ready and fails in a loop. | Give the database a health check and make the app wait for it to report healthy; a plain start-order dependency only waits for the container to start. |
| Between pointing the live name at the VPS and the certificate being issued, HTTPS to the live name is not valid. | Run every check on a temporary name first, time the issuance there, point the live name across only in a window you approve, or copy your existing certificate and key to the VPS yourself so the name is covered from the first moment (we never see the key). |
| Secret values end up in the Compose file, the image or the repository. | Rehearse with placeholders, place the production values on the server yourself through files outside the repository, and search the delivered files for any value before handover. |
An independent reviewer reads the production Compose file and proxy configuration for published ports, secret handling and restart behaviour before anything is applied. You approve the live change and hold the keys.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the services, the domain, the health check, the certificate route for the cutover and the evidence list in writing
- Rehearse the stack on a disposable machine running the same operating system release, with placeholder secrets
- Write the production Compose file and proxy configuration, with secrets supplied outside the file
- Independent review of published ports, restart and startup-order settings, and how secrets are passed
- Hand over the change set; you apply it, or we apply it through the time-limited account you create. You place the production secret values yourself
- Run the reboot test, the outside port check, the health check and the renewal dry run on the temporary name (or on the live name for a first launch), and record the output
- In the window you approve, you point the live name at the VPS; the certificate for it is requested straight away, and the certificate checks and the renewal dry run are repeated on the live name
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If you want the server patched and reviewed each month once it is running, ask about the monthly server patch and review service. This job does not include ongoing administration.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Docker documents the production changes it recommends for a Compose file, and a technical team can follow them itself. docs.docker.com
- A managed platform that builds and runs containers for you may be simpler if you do not want to administer a server at all.
Questions
Do I need Kubernetes for this?
No. One Compose project on one VPS is the whole scope. If the app has outgrown one host, say so in your enquiry and we will tell you honestly that this job does not fit.
Will the app restart if the server reboots?
It is set to, and the reboot test proves it on your server. The restart settings cannot protect you from a failing disk, a provider outage or a bug in the app.
Where do the secrets go?
Outside the Compose file and the repository. We rehearse with placeholder values; you place the real ones on the server yourself, generate them, hold them and rotate them. The handover lists where each one is read.
Can you deploy straight onto my live server?
Only through a time-limited, least-privilege account that you create and revoke, agreed in writing. The default is to hand you the change set to apply.
How does the certificate work when the name already serves a site?
The usual challenge needs the name to point at the new VPS, so we check everything on a temporary name first. At the cutover you point the live name across in a window you approve and the certificate is requested straight away, or you copy your existing certificate across yourself.
Send an enquiry
Send us
- The service names, images and published ports from your Compose file, with every secret value removed
- The VPS provider, the operating system release, and the domain name you want to use
- What the app does when it is working, and any URL that answers only when it is healthy
- Do not send passwords, keys, a .env file, server logins or customer data in the first enquiry
Later, once you agree
- A fresh VPS or a snapshot-protected one, and a time-limited administrator account you create and later revoke, or a rehearsal on a copy of the same OS release
- Read access to the images or source you want deployed, created by you with the least access needed
- Placeholder secret values for the rehearsal; you place the production secret values on the server yourself. You also make the DNS changes, first for the temporary name and then for the live name
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the VPS, domain, registry and secrets. We prepare the files and rehearse them on a disposable machine with the same operating system release, using placeholder secret values. A live deployment is run by you or through a time-limited, least-privilege account that you create and revoke, agreed in writing, and you place the production secret values on the server yourself. We never ask for a root password in the first enquiry, and the secrets stay yours to hold and rotate.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “compose-app-on-vps-with-tls-and-health-check” as the subject.