One compose per application
Each app lives under /opt with its own docker-compose. It starts, stops and updates on its own, without dragging the others along.
1 server → N apps · Self-hosted infrastructure
Multi-app VPS
A self-hosting pattern, documented and repeatable
what a new app needs
Files to add an app2
Database ports published0
Apps that need a restart0
Certificates renewed by hand0
The problem
Several applications sharing one VPS, each with its own database, without exposing ports or stepping on each other.
The decision
One compose per app, one central Nginx with one conf per app, and the databases on an internal network with not a single port published.
Central Nginx, one conf per app
A single reverse proxy with one configuration file per application. Adding an app means adding a file, not rewriting the configuration.
Databases on an internal network
Databases never publish ports to the outside: they live on an internal Docker network that only their application can reach. TLS is handled centrally by Certbot.
The result
A new app lands on the server with one compose and one conf, without touching what is already running. This site is deployed with the same pattern.
6
Apps under the pattern
10 min
To bring up and isolate a new app
0
Database ports published
Tech sheet
- Role
- Pattern design, implementation and maintenance.
- Orchestration
- Docker · Docker Compose, one compose per app under /opt
- Proxy
- Central Nginx, one configuration file per application
- TLS
- Centralized Certbot, automatic renewal
- CI/CD
- GitHub Actions: automated build and deployment to the VPS
- Network
- Shared Docker network for HTTP, internal network for the databases
- Scope
- Six applications in production on the same pattern: micaskin.com, this site and my own internal services.
Next case
Omnichannel messaging
Multi-tenant platform on top of WhatsApp for retail
Shall we work together?
Let's talk.
I design it, build it end to end and take ownership of keeping it running. Write to me and let's talk. I reply the same day.