Git Deploy for Discord Bots: The Push-to-Deploy Workflow

Uploading files through a file manager works for your first deploy. By the tenth, it’s a chore — and it’s easy to forget a file, overwrite a config, or lose track of which version is running. Git deploys fix that: your repository becomes the single source of truth, and pushing a commit is the deploy.

How git deploy works

On Kerit Cloud you link a GitHub repository to your bot’s server in the panel. From then on, every push:

1. Pulls the latest commit from the branch you chose.
2. Installs dependencies — npm, pip or Maven, depending on your runtime.
3. Restarts the bot with the new code.

The whole cycle is typically under 60 seconds. Your environment variables, data files and database stay exactly where they are; only the code changes.

Prepare the repository

A deployable repository has four properties.

It declares every dependency. package.json for Node.js, requirements.txt for Python, pom.xml or build.gradle for Java. The server installs from these files, not from whatever happens to be on your laptop.

It commits a lockfile. package-lock.json (or pnpm-lock.yaml, yarn.lock) pins exact versions so the server installs the same dependency tree you tested. For Python, pin versions in requirements.txt or generate it with pip freeze from a clean environment.

It excludes generated and secret files. A good .gitignore for a bot:

node_modules/
.venv/
__pycache__/
.env
*.sqlite
*.db
logs/

Never commit the database file or logs — a deploy would overwrite production data with your local copy.

It has an unambiguous start command. An npm start script, or a clear main.py entry point, so the host knows how to launch it.

Keep secrets out of git

The token, database passwords and API keys belong in environment variables set in the panel, not in the repository. Commit a .env.example listing the variable names so anyone cloning the project knows what to configure. If a secret has ever been committed, rotate it — see keeping your bot token safe.

Choose a branching model

The simplest model that works:

• main is production. The server deploys from it. Only tested code lands here.
• Feature branches (feat/tickets, fix/ping-crash) hold work in progress. Merge them into main through a pull request when ready.

If you want a staging environment, create a second bot application in the Developer Portal, run it on a second server that deploys from a staging branch, and test there before merging to main. Keep the two bots’ tokens separate so a staging bug can never touch production servers.

Check before you merge

A push to main goes live in under a minute, so it pays to catch mistakes before merging. A minimal GitHub Actions workflow that installs dependencies and runs a syntax check and tests:

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
  push:
    branches: [main]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint --if-present
      - run: npm test --if-present

For Python, swap in actions/setup-python and run pip install -r requirements.txt followed by python -m compileall . and your tests. Even a compile check catches the typo that would otherwise put your bot in a crash loop.

Protect the main branch in GitHub settings so pull requests can’t merge until the check passes.

Registering commands after a deploy

Deploying code doesn’t register slash commands with Discord — that’s a separate API call. Keep command registration as its own script or owner command and run it only when command definitions change. Registering on every start wastes API calls and can hit rate limits, especially since every push restarts the bot. Details are in deploying a discord.js v14 bot and hosting a discord.py bot.

Rolling back

When a deploy goes wrong, the fastest fix is to put the last working code back:

git revert HEAD      # creates a new commit that undoes the last one
git push             # deploys the reverted code

git revert is safer than git reset --hard plus a force push, because it keeps history intact and works cleanly when other people have pulled. If several commits need undoing, revert a range: git revert <good-sha>..HEAD. Git basics covers these commands in more detail.

Database changes need extra care

Code rolls back instantly; data doesn’t. If a deploy changes your database schema — adding a column, renaming a table — plan it so old and new code can both run:

1. Deploy a migration that adds the new column without removing the old one.
2. Deploy code that writes to both, then reads from the new one.
3. Once you’re confident, deploy a migration that removes the old column.

This expand-and-contract approach means a rollback never meets a schema it can’t handle. Schema migrations for bot developers explains the tooling.

What a restart costs

Each deploy restarts the bot, which means a few seconds offline while it reconnects. For most bots that’s invisible. To keep it that way:

• Batch small changes into one push rather than ten.
• Deploy during your quietest hours for big changes.
• Make startup fast — avoid fetching every member of every guild on boot.
• Handle SIGTERM so in-flight work finishes before the process exits.

A day-to-day workflow

git switch -c feat/leaderboard
# ...write code, test locally with your staging token...
git commit -am "Add weekly leaderboard"
git push -u origin feat/leaderboard
# open a pull request, wait for CI, merge into main
# → the server pulls, installs and restarts automatically

Watch the console for the first minute after a merge. If something breaks, revert and push, then fix it calmly on a branch.

Summary

Git deploy turns your repository into your deployment: link it once, and every push to your production branch pulls, installs and restarts the bot in under a minute. Commit lockfiles, keep secrets and data out of git, run a quick CI check before merging, register commands separately from deploys, and roll back with git revert. The result is fewer mistakes and a clear record of exactly what’s running.