Sites
Launch and run a real website — domains, TLS, a database, files, and git deploys — all from the site workspace.
A site is a website running inside one of your instances: a WordPress blog, a PHP, Node, Python, Go, or Rust app, or static files. You launch it once, then manage everything about it — domains, environment, files, deploys, and backups — from the site workspace, a set of tabs across the top of the page.
The tabs are: Overview · Networking · Environment · Cron · Monitoring · Files · Deploys · Backups · Settings. Some group related areas behind an inner toggle — Networking holds Domains, SSL, and Routes; Monitoring holds Logs and Health — and Access keys live inside Settings. The owner Terminal is a button in the top-right of the header, not a tab, so it stays open as you move between tabs.
Launching a site
From Sites → New site, a short wizard walks you through it:
Pick where it runs. Choose the instance to host the site. (If you came from an instance's Sites tab, it's already chosen.)
Choose a type. WordPress, PHP, static, Node, Python, Go, Rust, or Docker. Each installs the right stack. Anything missing on the instance is installed on the way.
Configure it. Name the site, set the environment values it asks for, and optionally turn on a database and site isolation (a dedicated owner — see Settings).
Launch. The launch runs live in a terminal. On success the site is live and you land in its workspace. On failure it's marked failed with a fix to apply — never a green light over a broken site — and you can resume from where it stopped.
The rest of this page tours the workspace tabs in order. The workspace remembers the tab you were on — switch to Environment, reload or come back later, and it opens there instead of snapping back to Overview (the same goes for the node and instance workspaces).
Overview
The home of the site: the chain node → instance → site, the live status, what to do next, and the credential handoff panel — one place to copy or email the site's endpoint, owner login, and database credentials to whoever runs it.
Networking
How requests reach the site, with an inner toggle between Domains and Routes.
Domains is where you spend your time: attach domains and manage their TLS certificates. SpipCP requests and renews Let's Encrypt certificates automatically, and each domain shows its certificate status and expiry.
| Control | What it does |
|---|---|
| Attach domain | Point a hostname at this site (creates the route + requests a certificate). |
| Wildcard subdomain | Optionally catch *.domain so every subdomain resolves to the site. |
| Certificate status | Issued / renewing / expiry, per domain. |
Routes is the lower-level view — the reverse-proxy routes behind the domains. Most of the time you manage domains and never touch this; it's here when you need to see or adjust the exact routing.
Changing a site's domain?
Attach the new domain, confirm it's live with its certificate issued, then remove the old one. Each domain has its own DNS, certificate, and route, so there's no separate "rename domain" — attach-then-detach is the change.
→ More detail: Domains & SSL.
Environment
The site's variables, edited two ways. The default .env view is a real code editor — line
numbers and syntax highlighting — where you can paste a whole .env straight out of VS Code. The
Table view is an aligned key/value grid. The site's predefined keys keep their labels and
validation, and you can add any extra SCREAMING_SNAKE_CASE key. Your # comments and blank lines
are saved and come back on reload. Save stages the change, then Apply relaunches to pick
it up. Platform-injected (SPIPCP_) and secret variables sit in a separate, locked card the editor
never touches.
| Control | What it does |
|---|---|
| .env / Table toggle | Switch between the .env code editor and the keyed table (same file). |
| Add variable | Add a key the blueprint didn't declare (still validated on save). |
| Save | Stage the new values + your raw .env text (comments kept) in the panel. |
| Apply changes | Relaunch the site so the new environment takes effect. |
| Copy / Download | Copy the .env to the clipboard, or save it as a file. |
WordPress sites have no .env file
The Environment tab is the one source of truth, but where the variables land depends on the site
type — WordPress renders them into wp-config.php, a Node app reads them as process env, a static
site has none. See Environment editor.
→ More detail: Environment editor.
Cron
Schedule recurring jobs and long-running background processes for the site, installed inside the instance. Add cron or worker opens a dialog where you pick the kind, name it, and set the schedule (for a cron) and command.
| Kind | What it does |
|---|---|
| cron | A scheduled job (a systemd OnCalendar timer). |
| worker | A continuously-running process that restarts on failure and survives reboot. |
Monitoring
Logs and health, with an inner toggle between the two.
Logs streams live output from the instance — useful when something misbehaves and you want to watch it in real time. Health shows the site's uptime and certificate checks at a glance (the site-scoped slice of Monitoring), plus — for an HTTP probe — latency percentiles (p50/p95) and a response-status chart so you can see not just whether the site is up, but how it's performing.
Files
A file browser scoped to the site's directory. Browse, view, and edit the site's files without opening a terminal or an SFTP client.
Deploys
Deploy the site straight from a git repository. Connect a repo (browse it through a git account or paste a clone URL), then deploy, roll back, and review the history.
| Control | What it does |
|---|---|
| Source | Connect or re-point the git repo and branch. |
| Deploy key | The per-repo key to register on the repository (read-only). Its name defaults to <site>-deploy so a site's keys stay distinguishable; rename it before generating. |
| Deploy now | Run the fetch → build → release pipeline. |
| Rollback | Flip back to a previous release (health-checked again). |
| Webhook | A push URL + secret so a git push redeploys automatically. |
A deploy timeline chart shows each run's duration and outcome, so you can spot a deploy that's started taking longer or a run of failures at a glance.
→ More detail: Git deploys.
Backups
Schedule and run backups of the site, and restore from one. Backups can run on a schedule or on demand, and a restore brings the site back to a chosen point. Transfer app here moves the site to another node or instance in one click (the source keeps serving until the move is health-checked).
A backup-health chart tracks size over time alongside the success rate, so a growing backup or a run of failures shows up before you need the backup.
→ More detail: Backups · Restore & clone · Transfer an app.
Settings
Site-level options, lifecycle actions, and per-site access keys.
| Control | What it does |
|---|---|
| Name | Rename the site. The name is a display label only — renaming is instant and changes nothing inside the instance. |
| Tag | A free-text label to organise sites. |
| Stop / Start | Take the site offline or bring it back. |
| Access keys | SFTP/deploy keys scoped to this site only — see below. |
| Delete | Remove the site (with confirmation) and tear down its resources. |
Renaming a site
Edit the Name field and Save name. A site's name is just a display label with no behaviour attached — the owner comes from the domain, routes from the hostname — so a rename touches nothing in the instance and needs no relaunch. (To change the domain, see Networking.)
Access keys
SFTP and deploy keys scoped to this site only, managed from inside Settings. Give a developer file access to their site without a panel login or access to anything else on the box. Add developer key opens a dialog — paste their SSH public key and name it. The key maps to a per-site SFTP user confined to the site root, never a panel login.
→ More detail: Access keys.
Site isolation (the owner)
With isolation on (the default), the site gets its own Linux owner inside the instance — a user that owns the site's files and is walled off from the other sites on the box, with a narrow, safe permission grant. The owner's login is part of the credential handoff on the Overview tab.
→ More detail: Site owners · Site database & handoff.
Terminal
The owner Terminal is a button in the top-right of the workspace header (a floating window that stays open while you switch tabs), not a tab. When the site is isolated, you log in as the site owner (not root), so the terminal can only touch this site's files. It's available once the site is live.
How it works
Each site type installs through a series of steps run inside the instance. A deploy builds a new release in its own directory and switches to it in one atomic move, so a request in flight never sees a half-deployed site, and any release is one click from rollback. Launch, deploy, and backup all run through the node agent — the panel decides, the agent acts.
Docker management
See and control every container across your whole fleet — status, health, CPU/mem/size, start/stop/restart/recreate/pull, live logs, and alerts — from one screen, with three zoom levels (fleet → instance → app).
Domains & SSL
Give a site a real hostname with automatic HTTPS — point one DNS record at it, and SpipCP handles the certificate, renewal, and a check that it actually serves.