GitBlixt
Docs Navigation

Deploying GitBlixt

Architecture

GitBlixt runs as Docker Swarm services: the app itself, plus the gitblixt stack (Postgres, MariaDB and Caddy) deployed from docker-compose.yml:

  • PostgreSQL 18 — stores all application data (users, repositories, issues, etc.)
  • GitBlixt (Elixir/Phoenix) — the application itself. Handles HTTP, SSH, and git operations.
  • Caddy — owns ports 80/443, terminates SSL (Let's Encrypt), and proxies your GitBlixt domain to the app. It also routes domains for repositories deployed via App Deployment .

On first boot, the GitBlixt container automatically:

  1. Waits for PostgreSQL to be healthy
  2. Runs all database migrations
  3. Generates SSH host keys

Caddy requests the SSL certificate for your domain from Let's Encrypt.

Standard Deployment

Run the one-line installer described in Getting Started .

Using an External Database

To use your own Postgres instance instead of the bundled one, set DATABASE_URL in the gitblixt service and remove the postgres service from your compose file: 

    services:
  gitblixt:
    image: willc0de4food/gitblixt:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "22:22"
    environment:
      DATABASE_URL: ecto://user:pass@your-db-host:5432/gitblixt
      GITBLIXT_HOST: git.yourdomain.com
    volumes:
      - ./data:/data

Minimum Postgres version: 14.

Data Storage

Persistent data is stored across two locations:

Location Contents
data/postgres/ PostgreSQL data directory (managed by the postgres container)
/data/repos Bare git repositories
/data/uploads User avatars and file uploads
/data/ssl Let's Encrypt certificates
/data/ssh SSH host keys (auto-generated on first boot)

Firewall Requirements

Port Protocol Purpose
80 TCP HTTP (redirects to HTTPS; also used for Let's Encrypt ACME challenges)
443 TCP HTTPS
22 TCP Git over SSH

If port 22 is already in use by your server's own SSH daemon, you can run GitBlixt's SSH on a different port with -e GITBLIXT_SSH_PORT=2222 and expose it with -p 2222:2222. Users will then clone with git clone ssh://git@git.teagles.io:2222/user/repo.git.

Container-to-Host Firewall

Deployed apps and CI/AI job containers run on Docker networks attached to this host, so by default they can reach any host service listening on the Docker bridge addresses or on 0.0.0.0. The optional firewall.sh script (downloaded by the installer, also at https://git.teagles.io/firewall.sh) closes that off: it adds a GITBLIXT-HOST iptables chain for traffic arriving from Docker interfaces (docker0, docker_gwbridge, br-*) that allows replies to host-initiated connections and the TCP ports you list, and drops everything else. Traffic between containers and to the internet is unaffected. 

    sudo bash firewall.sh              # apply (safe to re-run)
sudo bash firewall.sh --dry-run    # print the commands without running them
sudo bash firewall.sh --remove     # remove the rules and the boot-time unit
  • GITBLIXT_HOST_ALLOW_PORTS — comma-separated host TCP ports containers may reach (default: none). If your apps or GitBlixt itself use a Postgres running on the host (e.g. a DATABASE_URL pointing at host.docker.internal), allow 5432: sudo GITBLIXT_HOST_ALLOW_PORTS=5432 bash firewall.sh. If containers call domains served by this same host through its public address, allow 80,443 too.
  • GITBLIXT_HOST_ALLOW_DNS=1 — also allow DNS (port 53). Only needed if you point containers at a resolver running on the host; Docker's built-in DNS works without it.
  • On systemd hosts the script installs gitblixt-firewall.service, which re-applies the rules (with the same settings) at boot. It works with both the iptables-nft and iptables-legacy backends.
  • The installer applies it when run with GITBLIXT_FIREWALL=1 (or when you answer yes at the prompt).