Docs · Running your bot

Deploying from GitHub

All docs

Put your repository's link in the panel and your bot is deployed from it: cloned on the next start, and updated with your newest commits every time it restarts after that. Push, press Restart, done.

Setting it up

  1. In Files, delete anything you uploaded yourself. Our starter files can stay, the clone replaces them. If anything else is there, nothing is cloned, so your own files are never overwritten by accident.
  2. On Startup, paste the link into Git repository. The link from the repository's main page is right: https://github.com/you/your-bot. A link to a branch such as .../tree/dev works too.
  3. For a branch other than the default one, put its name in Git branch.
  4. If the repository is private, add a token (below).
  5. Open Console and press Restart.

You should see:

[SnowServers] Cloning https://github.com/you/your-bot
[SnowServers] Deployed 3f2a91c Add /remind command
[SnowServers] Installing requirements.txt

GitHub, GitLab, Codeberg and Bitbucket are supported.

Deploying a change

Push to the branch, then press Restart. The console shows Updated from Git: and the commit it moved to, or up to date if there was nothing new. Packages are reinstalled only if requirements.txt or package.json changed in that push.

To stop updating on every start (for example while you test something on the server), turn off Update from Git on start. The bot keeps running the commit it is on.

Private repositories

Make a token that can only read that one repository, and paste it into Git access token. It is used when cloning and pulling, and is never written into the server's files.

GitHub

  1. GitHub, your picture, Settings, Developer settings, Personal access tokens, Fine-grained tokens, Generate new token.
  2. Repository access: Only select repositories, and pick your bot's repository.
  3. Permissions: under repository permissions, set Contents to Read-only. Nothing else.
  4. Pick an expiry, generate it, and copy the token (it starts with github_pat_).

GitLab

Your avatar, Edit profile, Access tokens, Add new token, with only the read_repository scope.

When the token expires, cloning and pulling stop with a message in the console. The bot keeps running the code it already has. Make a new token and paste it in.

Anyone you give access to this server's Startup page can see the token. That is why it should only be able to read one repository.

What never gets overwritten

  • Files your bot creates that are not in the repository: a SQLite database, a JSON file of settings, logs. Updates leave them alone.
  • Your .env file. If the repository also has one when it is first cloned, the repository's is saved next to yours as .env.from-git.
  • Files here that a new commit adds. If a commit adds a file you already have on the server (a .env or a data file of the same name), the update is skipped and the console names the file. Rename or delete it here, then restart.
  • Files from the repository that you edited on the server. If a new commit changes the same file, the update is skipped and the console lists the file. Make the same change in your repository, or delete the edited file here, then restart.

If you rewrite the branch's history (a force push), the server moves to the new history as long as that would not overwrite anything above. Otherwise it stays where it is and says why.

Switching an existing server to Git

Download a backup first. In Files, delete your bot's code: its .py or .js files, requirements.txt or package.json, and any folder with code in it. .env and data files (a database, a settings file, a data folder) can stay, as long as the repository has no file of the same name. Set Git repository and restart. The console lists the files it kept.

Switching repositories

Change Git repository and restart. The server moves to the new repository, on its default branch unless Git branch says otherwise, as long as you have not edited the old repository's files here and the new one has no file with the same name as an untracked file of yours. If either is in the way, the console says which file.

Restarting automatically when you push

The Deploys tab gives your server a deploy address. Add it to your repository as a webhook, and every push to the branch the server follows restarts it, which pulls the push. No API key, no workflow file.

  1. In the panel, open Deploys and press Turn on deploy on push. Copy the address. It is shown once; if you lose it, make a new one there and the old one stops working.
  2. GitHub: the repository's Settings, Webhooks, Add webhook. Payload URL: the address. Content type: application/json. Leave Secret empty. Just the push event.
  3. GitLab: Settings, Webhooks, Add new webhook, with Push events ticked.
  4. Bitbucket: Repository settings, Webhooks, Add webhook, trigger Repository push.

The Deploys tab lists the last pushes and what happened to each, and which commit each bot is running now, so you can see a push has landed. If a bot crashes within a few minutes of starting on a push's code, the push says so, with the reason and a link to that bot's logs. With a crash alert webhook set, each deploy also posts a short Deployed message to that channel. A push restarts the server only if it is to the repository and branch set on Startup (or in a bot's .env, for more than one bot), so a push to a feature branch does nothing. Several pushes within 30 seconds give one more restart at the end, so the newest commit is always the one running. A server you stopped stays stopped.

With several bots on one server, a push to a repository that only a bot in bots follows updates just that bot: it is stopped, pulled, its packages reinstalled if they changed, and started again, while the others keep running. You can do the same by hand by typing bots update NAME in the console.

The address works with no Git host too: curl -X POST -A deploy ADDRESS from a CI job restarts the server after your tests pass. Keep the -A: requests with curl's default name are stopped by our DDoS protection before they reach us. Anyone with the address can restart your server, so keep it in your CI's secrets, not in the repository.

Something here wrong or out of date? Tell us and it gets fixed.