Hosting architectures

Choosing one of three hosting architectures is the first decision when you put an application on your account. Most software clearly belongs to one.

	Your app is	Runs as	Choose it for
Direct serving	Files in the website's document root.	The dedicated web user.	PHP software you upload and open in the browser.
App server	A program of yours that runs continuously and speaks HTTP.	Your login user.	An application you build or deploy from source.
Container	A prebuilt OCI image, or a stack in compose format.	Your login user, without root.	Software that comes as a Docker image, or a stack of several pieces.

Direct serving

Your application is the files in the website's document root, e.g. PHP under public/example.com/, and the web server runs them in place. WordPress and most standard PHP software work this way.

• Setup: upload the files; no mount, no process to manage. Pick a PHP version per directory if the default isn't right.
• Containment: the code runs as the dedicated web user, so a compromised plugin can only touch what you granted through web permissions. See the user security model.
• How to recognize it: the install guide talks about document roots and .htaccess.

App server

Your application is a program of yours that runs continuously: Node, Python, Go, anything that speaks HTTP. The panel supervises it, gives it a private address, starts it when a request arrives, stops it when idle, and collects its logs.

• Setup: an executable in your home directory that binds the address the panel gives it in $IP and $PORT, plus a mount to give it a URL.
• How to recognize it: npm start, gunicorn, or a compiled binary.

Container

Your application comes as a prebuilt OCI image, or as a stack of images in compose format. The panel runs it with volumes, health checks, and restart policies.

• Setup: an image reference or a compose file, published ports, and a mount to expose it on a website.
• Containment: the container runs without root, and the image boundary is a second layer.
• How to recognize it: the software brings its own runtime or system dependencies, or it's a stack of an app with a database and a cache.

The three mix freely on one site

One website can serve a direct WordPress at /, an API app server at /api, and a container service at /search.

How an app attaches: mounts and the proxy

A direct site is served from its files, with no proxy in between. The other two run as separate programs, and a mount attaches one to a URL path on a website of yours. The panel's reverse proxy connects the two: visitors speak HTTPS to your domain, and the proxy forwards matching requests to your app.

https://example.com/            ──→  files in public/example.com/
https://example.com/api/…       ──→  mount → your app server (private address)
https://example.com/media/…     ──→  mount → another directory in your home

A mount maps a URL path to a backend: an app server, a port where a process of yours listens (usually one a container publishes), or another directory in your home for more static files. Overlapping paths go to the most specific one. The mechanics are in Mounts.

Two things follow from the proxy:

• Your app never handles TLS, certificates, or public exposure. It binds a private address, reachable only from your own account, and speaks plain HTTP to the proxy.
• An app server stops when idle and starts again at the next request, so expect a short start delay after a quiet period. A container keeps running.

A container secret stays out of the panel

If you pass secrets through an environment file, the panel stores only its path; the container reads the contents from your home directory at start. They never enter the panel's database or configuration.

Availability

note

App servers, containers, mounts, and the code editor need persistent services, which your provider turns on per account. If an Applications feature refuses with such a message, ask your administrator.