Chapter 01
Your app runs in a container. A domain points at it.
That single sentence is the whole platform. Everything in this guide is a stop along that path — the folder your code lives in, the image that runs it, the domain that reaches it, and the gate that can stand in front.
The path below is the common case: a catalog site, one container from an image the platform already built. If your app needs its own database engine, several containers, or a runtime you build yourself, you want a custom stack instead — same edge, same certificates, a different way of getting there. Chapter 02 puts the two side by side; read it before you create anything.
What you are responsible for
The platform gives you a running container, a routed domain, and a certificate. It does not touch your application. The split is sharper than on most hosts, so it is worth stating plainly.
| The platform does | You do |
|---|---|
| Runs a container for your site and restarts it if it dies | Put your application files in the site folder — a Laravel app goes in its application/ subdirectory |
| Routes your domain to it and issues the HTTPS certificate | Point the DNS record at the box before publishing |
| Serves the folder with nginx, and PHP-FPM on the Laravel image | Ship a working app — the health check does not test it |
| Runs the background programs you declare | Write those program definitions and keep them valid |
| Provides shared MySQL and Redis on the internal network | Get your own database and credentials, and configure your app |
On a catalog site there is no build step: you copy files into the site folder yourself, or let the in-container runner do it on every push (chapter 10). And because PHP opcache is set to never re-check timestamps, your changed code does not go live until the container is restarted. Chapter 04 covers what this means in practice.
A custom stack is the opposite arrangement — the source is always git, the panel clones and builds it, and you press Deploy. Chapter 02.2.
Getting around the panel
Everything in this guide starts the same way: sign in, open a site from the list, then pick a tab. The rest of the panel — the platform-wide pages your account is allowed — is in the menu down the left side. It ends with the address you are signed in as and two small icon buttons beside it: one opens Your account, the other signs you out. If you learned an earlier version of the panel, that is where the full-width Sign out button went.
On a narrow screen that menu is behind the ☰ button in the top bar. Tap it and the menu slides in over a dimmed page; it closes when you tap outside it, press Escape, use the ✕ in its corner, or simply choose where you are going. Nothing is missing from it — the sections, the light and dark control, the signed-in address and both of its buttons are all there.
Every page is laid out for the width it is given, down to 320px, so nothing needs pinching or sideways scrolling. Lists become one card per entry rather than a squeezed table, and a site's actions — Publish, Restart, Recreate, Delete — stack full-width under its name. Backup listings keep their table and scroll inside their own box, because a date and a size mean nothing without their headings.
Two things are still happier on a big screen, and both for the same reason — long lines: the environment-file editor, and the build output a stack prints while deploying. Everything else is a fair phone job.
The vocabulary
A handful of words carry most of the meaning. They mean the same thing in this guide and in the panel.
- Site
- One thing the panel runs. It comes in two kinds — a catalog site or a custom stack — and everything below applies to both unless it says otherwise. Chapter 02.
- Catalog site
- A domain, an image, and a folder. One container runs it. The common case.
- Custom stack
- A Docker Compose project built from your git repository. As many containers as your compose file declares, and no domain of its own — it is named by a slug, and domains are pointed at it afterwards.
- Folder
- A directory holding your code, mounted into the container at the identical path: under
/var/www/virtual/for a catalog site, under/var/www/stacks/for a stack. - Image
- The runtime a catalog site uses — a static web server, PHP 8.3, or whatever else your box's Site Images page holds, which an administrator can add to. Chosen from that list when the site is created. A stack brings its own images instead.
- Published
- Whether a domain currently routes to your site. A catalog site can run without being published; for a stack, a domain row exists exactly when it is served.
- Locked
- Whether the whole site, or certain URL paths, answer only to unlocked IP addresses. Everyone else gets a 403.
- Site owner
- The kind of panel account this guide is written for. You sign in and the sites list holds your sites — every one of them yours to publish, deploy, lock and delete. Other people's sites are not listed and not reachable. An administrator account sees every site on the box and the platform-wide pages besides; an unlock-only account gets neither, just the page for unlocking its own address. Chapter 08.
Where to go next
The chapters build on each other in order. If you are setting up a site for the first time, read them straight through — it is about fifteen minutes. If you are here with a specific problem, jump.
if: always() matters.