One VPS. Room for more than one app.

You can run several web apps on one VPS. Each app needs its own process and listening port. A reverse proxy routes each domain to the right app, so visitors use ordinary HTTPS addresses without port numbers.

In hosted ForgeVPS, each GitHub deployment has its own app entry, port, environment file, and deployment history. This guide uses that workflow. GitHub deployments are not yet available in the self-hosted preview. If this is your first deployment, start with the complete app deployment walkthrough.

Give every app a distinct port

Imagine a portfolio and a small API on the same machine. The portfolio could listen on 3000 and the API on 3001. These numbers are examples: use the ports shown in your ForgeVPS app entries.

• www.example.com → Caddy → portfolio on its assigned port.
• api.example.com → Caddy → API on a different assigned port.

Both hostnames can point to the same public IP address. Caddy receives traffic on ports 80 and 443 and chooses an app using the requested hostname. Your application processes should not each try to listen on 443.

Deploy the second project

1. Open the machine's Servers pane and choose Connect a repo again.
2. Select the second repository and its deployment branch. Give it a distinct name, such as portfolio-api.
3. Check its install, build, and production start commands. Different frameworks can need different commands.
4. Leave Port blank to let ForgeVPS assign one. Check that the app reads process.env.PORT, or your runtime's equivalent.
5. Choose Connect & deploy, follow Deployments, then check the running app's Logs.

Auto-assignment avoids ports recorded for other ForgeVPS deployment entries. If you also run processes manually, inspect those before choosing a port: an untracked process can still occupy it. An EADDRINUSE error means the requested address and port are already in use.

A development server and a production deployment of the same project also need distinct ports if both run at once. Stop an unneeded preview through its own controls; do not stop an unidentified process just to free a port.

Connect one hostname to each app

For the portfolio, open its Domains tab and add www.example.com. For the API, open that app's Domains tab and add api.example.com. Replace these examples with names you own.

At your DNS provider, create an A record for each hostname with the same VPS IPv4 address. Use Check DNS in ForgeVPS to check the result. The hostnames differ even though the IP is shared. Assign a hostname to only one app on the machine.

Ports 80 and 443 must reach Caddy through both firewall layers. You do not need to expose every app's internal port publicly for domain-based access. Caddy's HTTPS documentation explains the certificate and network requirements.

Open both public URLs and verify that each shows its own content. If both display the same app, check which app owns each domain and whether a DNS record points at an older machine.

Keep configuration and data separate

Use each app's Env tab for its own settings. Save and redeploy after changing them, and make sure the app loads its linked .env file. A payment key or database URL for the API should not be copied into the portfolio simply because they share a VPS.

For unrelated projects, separate databases and database credentials make permissions and recovery easier to reason about. Keep uploaded files and other persistent data outside disposable release directories. Test a database restore before you need one.

Separate app entries do not provide a security boundary equivalent to separate machines. The apps still share the VPS, its operating system, and resources. Use stronger isolation or separate servers when projects have different trust levels or require independent failure boundaries.

Check capacity before adding more

There is no useful universal number of apps per VPS. Two quiet sites can use fewer resources than one busy app. Builds, databases, scheduled jobs, and coding assistants all compete for CPU, memory, and disk alongside web traffic.

Watch machine usage during normal traffic and during a deployment. Leave memory for build-time spikes and disk space for releases, logs, uploads, and backups. If a build repeatedly kills another app or the machine runs out of memory, reduce concurrent work or increase capacity before adding another project.

Finally, deploy an update to one app and check that the other still responds. Keep each app's branch, port, domains, and database connection documented. When something fails, trace the failing stage before changing settings across the whole machine.