PremiumComes with the add-on reqad-account. Installing add-ons

Deploy & apps

The Deploy & apps group of the account panel: deploy a site from a Git repository, and run a Node.js or Python app behind one of your domains.

Setting these up needs an account with a full shell, because build commands and apps run as your account outside any jail. Without one you can still deploy, roll back, start and stop what your hosting provider set up for you. The server panel's side is described in Git deployments and Node.js & Python apps.

Git deployments

Push to your repository and the site updates itself:

1. The server fetches the branch with its own key (a deploy key you give read access to).
2. It unpacks the commit into a new release folder in ~/apps/<domain>/ and runs your build commands there, as you. The first one that fails stops the deploy, and the site stays as it was.
3. Only when that worked does the site switch to the new release, at once. If the health check page does not answer, it goes back.

When you add a deployment, choose the site, the repository address and the branch, and optionally a starting point that fills in the fields (Start from), the build commands (one per line, such as composer install or npm ci && npm run build), the public folder, a health check page and the shared paths: files that must stay between releases, such as .env or uploads/, kept once and linked into every release. The first deploy moves the files that were in the site's folder aside to a folder named ...before-deploy-<date>; nothing is deleted.

Deploy key and webhook shows what to add to the repository:

• The deploy key, with read access only: GitHub: Settings > Deploy keys. GitLab: Settings > Repository > Deploy keys. Bitbucket: Repository settings > Access keys. Gitea / Forgejo: Settings > Deploy keys. A public repository with an https:// address needs no key; a private one uses the SSH address (git@...).
• The webhook, to deploy on every push: GitHub: Settings > Webhooks > Add webhook, content type application/json, just the push event. GitLab: Settings > Webhooks, Push events, the secret as Secret token. Bitbucket, Gitea and Forgejo work the same way. Without it, press Deploy after you push.

Roll back switches the site to one of the releases kept on the server (Releases kept sets how many), at once.

Node.js and Python apps

Run a Node.js or Python program (Express, Next.js, Django, Flask, FastAPI...) for one of your sites: it starts with the server, restarts if it crashes, and the site's visitors reach it through the web server.

• Choose the site, the runtime and its version (those your hosting provider installed), the app's folder and the start command. The panel reads the code and fills it in (Django, Flask, FastAPI, Next.js, Nuxt, the start script of package.json...); the buttons under it are the other commands it found. With Git and no code on the server yet, leave it empty: the first deploy finds it. It runs as you, in the app's folder, must keep running and must listen on the port in $PORT (host 127.0.0.1).
• Environment: KEY=value lines for settings such as database passwords, kept out of the code. PORT and HOST are set by the server. Saving restarts the app.
• Serve existing files first: files in the folder (images, CSS) are sent by the web server directly.
• A memory limit: if the app uses more, it is restarted.

Put the code in the folder with the file manager, SFTP or a Git deployment, and press Install packages: it reads requirements.txt or pyproject.toml (into the app's own .venv) or package.json, installs what they list and restarts the app (details). With a Git deployment this happens by itself at every deploy. While the site has an app it no longer runs PHP. If nothing answers on the port, the page says so; Its output shows why. Removing the app gives the site back its usual setup.

Need a hand? Create a free account or contact us.