Chapter 02
What a site is
A site is three things bound together: a domain, an image, and a folder. Creating one gives you a running container. Everything else in this guide adjusts one of those three.
The folder
Every site has a folder on the host, under /var/www/virtual/. When a site is created the folder defaults to the domain name, so app.example.com gets /var/www/virtual/app.example.com. A folder outside that base directory is rejected.
The important property: the folder is mounted into the container at exactly the same path. There is no mapping to remember. A file at /var/www/virtual/app.example.com/application/artisan on the host is at that same path inside the container. This is why absolute paths in your background programs work in both places — see chapter 05.
The panel creates the folder if it is missing. Beyond that it never reads, writes, or clears the contents — not on a restart, not on a settings change, not when the image changes.
Where the docroot points
This differs by image, and it is the first thing that trips people up.
| Image | Docroot | So your files look like |
|---|---|---|
| Static Website web-base |
<folder> | <folder>/index.html |
| Laravel App laravel |
<folder>/application/public | <folder>/application/public/index.php <folder>/application/artisan <folder>/application/vendor |
On the Laravel image the application lives in an application/ subdirectory of the folder, and only its public/ is exposed to the web. That is the standard Laravel layout, and it means your vendor/ and the app's own .env and storage/ symlinks sit outside the docroot where they belong.
Two pieces of durable state live beside application/, not inside it: <folder>/storage/ (uploads, logs, sessions — the standard Laravel tree, scaffolded for you by the image) and <folder>/.env (your secrets). A deploy symlinks both back into application/, so it can wipe and re-publish application/ on every push without ever touching your data or secrets. See chapter 04.
If the docroot has no index.php or index.html, the Laravel image writes a placeholder page saying the image is running with no app deployed. Seeing that page means the container is healthy and waiting for your code — not that something broke.
The container
One container runs one site. It is named after the domain, with dots turned into dashes and an no- prefix: app.example.com becomes no-app-example-com. You will see this name in the panel and in log output.
Containers have no published host ports. Nothing about your site is reachable at the-box-ip:8080 or similar. Traffic arrives only through the edge proxy, which dials your container by name on the internal network. This is also why your app can reach shared services by name — covered in chapter 06.
Created is not published
These are two separate actions, and the split is deliberate.
- Created
- The folder exists, the container runs, and the site is reachable from nowhere. Nothing is routed to it and no certificate has been requested.
- Published
- The domain is routed to your container and a certificate is issued. This is the point at which DNS must already be correct.
- Unpublished
- The route is withdrawn. The container keeps running and your files are untouched — the site is just unreachable.
You can safely create a site, get your code in place, confirm it works, and publish afterwards. Unpublishing is not destructive and is the right way to take a site offline temporarily.
What the status dot means
The panel shows a live status for each site, derived from the container's health check at the moment you look. It is not stored and not historical.
- Up
- The container is running and its health check passes.
- Starting
- The container is running but has not yet reported healthy. The Laravel image allows 20 seconds before it starts counting failures.
- Down
- The container is stopped, missing, or failing its health check.
The health check asks nginx for /health, which returns a fixed 200 without touching PHP, and confirms the docroot is readable. On the Laravel image it also checks that php-fpm and supervisor are running as processes.
It never executes your application. A site with a fatal PHP error, a missing vendor/, or a broken database connection reports Up quite happily. Always confirm a deploy by loading a real page.
Restarting
The panel offers a restart action for a site. You will need it more often than you might expect, because it is how newly deployed PHP code and newly added background programs take effect. Both are covered next.