Deployment

Docker

docker pull ghcr.io/contriboss/vein:latest

docker run -d \
  --name vein \
  -p 8346:8346 \
  -v vein-data:/data \
  -e RUST_LOG=info \
  ghcr.io/contriboss/vein:latest

docker logs -f vein

Custom configuration

cp vein.example.toml vein.toml
# edit vein.toml...

docker run -d \
  --name vein \
  -p 8346:8346 \
  -v $(pwd)/vein.toml:/data/vein.toml:ro \
  -v vein-data:/data \
  vein:latest serve --config /data/vein.toml

Docker Compose

The repository’s docker-compose.yml spins up a fully configured, production-ready stack with a PostgreSQL backend:

git clone https://github.com/contriboss/vein.git
cd vein
docker compose up -d

docker compose ps        # both services should show "healthy"
docker compose logs -f vein
docker compose down

What’s included:

• PostgreSQL 18 with persistent storage, healthchecked before Vein starts
• Vein proxy with auto-migrations - no manual setup
• Healthchecks for both services (GET /up for Vein)
• Preconfigured bridge network

Point Bundler, Cargo, or npm at http://localhost:8346 and you’re done. A test service in the same compose file demonstrates pointing GEM_HOST, CARGO_REGISTRIES_CRATES_IO_*, and NPM_CONFIG_REGISTRY at the running proxy.

systemd

[Unit]
Description=Vein Package Proxy
After=network.target

[Service]
Type=simple
User=vein
ExecStart=/usr/local/bin/vein serve --config /etc/vein/vein.toml
Restart=always

[Install]
WantedBy=multi-user.target

Behind Nginx

upstream vein {
    server localhost:8346;
}

server {
    listen 443 ssl http2;
    server_name packages.company.com;

    location / {
        proxy_pass http://vein;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Health checks

curl -fsS http://localhost:8346/up
# or
vein health --url http://localhost:8346/up --timeout 5