CSSTEP 01Share the machine, separate the applications
Give each app its own runtime, credentials and persistent storage. Sharing a VPS means sharing its CPU, RAM, disk and failure domain. A resource-heavy build or worker can affect the other projects, so monitor capacity and leave headroom.
STEP 02Use one edge proxy
Only one process can own the same host port. Let one Caddy instance handle ports 80 and 443 and route by hostname. For host-based apps bound to different loopback ports, the following example keeps both application ports private.
first.example.com {
reverse_proxy 127.0.0.1:3001
}
second.example.com {
reverse_proxy 127.0.0.1:3002
}STEP 03Separate releases and permissions
Use separate service users or appropriately isolated containers. Do not let one app read every other app’s .env files. Track which service owns each port, domain and database. Deploy one app without restarting all the others.
STEP 04Know when to split the server
Separate machines may be worthwhile when a project needs a stronger security boundary, independent maintenance, predictable capacity or higher availability. Multiple apps on one VPS is a practical starting point, not automatic high availability.
COPY → YOUR AI
Take the next step to your AI.
A safe starting prompt for this guide. No secrets. Works with ChatGPT, Claude and other assistants.
Sources and technical documentation
Caddy automatic HTTPS ↗Docker documentation ↗This recipe is a pattern for the stated prerequisites. Verify project compatibility and your actual server configuration before applying it to a live service.