Remote Management¶

Manage your cloud deployment with dango remote commands.

Quick Reference¶

All commands require an active deployment (.dango/cloud.yml must exist). They work the same for both DigitalOcean and BYOS deployments — all communication happens over SSH.

Pushing Changes¶

After making local changes to configuration or dbt models, push them to the server:

dango remote push

What Gets Synced¶

Config files (uploaded via SFTP):

dbt directories (synced via rsync with --delete):

• dbt/models/ — all model SQL files
• dbt/macros/ — all macro SQL files

Files that don't exist locally are skipped.

What Is NOT Synced¶

These files are managed separately and never overwritten by push:

• .env — environment variables (see Environment Variables)
• .dlt/secrets.toml — API credentials
• warehouse.duckdb — the DuckDB database
• Metabase H2 database — Metabase configuration and saved questions
• dbt/profiles.yml — auto-generated for server hardware

Git Guardrails¶

By default, dango remote push checks your git state before deploying:

• Branch check — warns if you're not on the expected branch (e.g., main)
• Dirty check — warns if you have uncommitted changes

Override with flags:

# Allow uncommitted changes
dango remote push --allow-dirty

# Allow deployment from any branch
dango remote push --allow-branch

# Both
dango remote push --allow-dirty --allow-branch

Pre-Deploy Backup¶

Every push automatically creates a backup on the server before applying changes. This backup is used by dango remote rollback if something goes wrong.

Deploy Lock¶

Only one push can run at a time. If another push is in progress, you'll see an error. Use --force to override a stale lock:

dango remote push --force

Dry Run¶

Preview what would be synced without making changes:

dango remote push --dry-run

This shows which files changed, which dbt models were added/modified/removed, and whether macros or packages changed — without uploading anything.

Push Options¶

Change Detection¶

Push uses MD5 hashing to detect changes:

• Model changes — individual *.sql files in dbt/models/ are compared. Changed models trigger selective dbt run --select
• Macro changes — any change in dbt/macros/ triggers a full dbt run (macros aren't individually selectable)
• Package changes — if dbt/packages.yml changed, dbt deps runs before dbt run
• First deploy — all local models are treated as "added" and a full dbt run executes

Example Output¶

Syncing project files...
  ✓ .dango/sources.yml (changed)
  ✓ .dango/schedules.yml (unchanged, skipped)
  ✓ dbt/models/staging/stg_stripe_charges.sql (new)
  ✓ dbt/models/marts/mrr.sql (changed)

Changes detected:
  Added models: stg_stripe_charges
  Changed models: mrr
  Packages: unchanged

Creating pre-deploy backup...
  ✓ Backup: backup-20260515-143000.tar.gz

Running dbt...
  ✓ dbt run --select stg_stripe_charges mrr
  ✓ 2 models completed

Deploy complete.

Rolling Back¶

Restore the server to its state before the last push:

dango remote rollback

This uses the most recent pre-deploy backup. To restore from a specific backup:

dango remote rollback --backup /srv/dango/backups/deploy/backup-20260515-143000.tar.gz

Rollback workflow:

1. Stop services (dango-web, Metabase)
2. Extract backup archive
3. Restore all files (config, database, Metabase data)
4. Restart services
5. Verify health

Checking Status¶

View a comprehensive overview of your deployment:

dango remote status

Output panels:

Server: 143.198.xxx.xxx
Region: nyc1 (New York 1)
Size:   Standard (s-2vcpu-4gb) — $24/mo
Domain: analytics.yourcompany.com

Services:
  ✓ Dango web server (running)
  ✓ Metabase (running)
  ✓ Caddy (running)

Resources:
  CPU:  12%
  RAM:  1.8 GB / 4.0 GB (45%)
  Disk: 14.2 GB / 80.0 GB (18%)

Data:
  DuckDB: 256 MB
  Last sync: stripe (2 hours ago), hubspot (6 hours ago)

Versions:
  Installed: 1.0.0
  Latest:    1.0.0

Last Deployment:
  Commit: a1b2c3d (main)
  By: deploy@local
  At: 2026-05-15 14:30:00

Backup:
  Last: backup-20260515-020000.tar.gz (13 hours ago)

Viewing Logs¶

View service logs from the server:

# Dango web server logs (default)
dango remote logs

# Specific service
dango remote logs --service caddy
dango remote logs --service metabase

# Last 100 lines
dango remote logs --tail 100

# Stream logs in real-time (Ctrl+C to stop)
dango remote logs --follow

Log sources by service:

Interactive SSH¶

Open an interactive SSH session to the server:

dango remote ssh

This connects as root with full shell access. The command replaces your current process — when you exit the SSH session, you're back in your local terminal.

Querying Data¶

Run a read-only SQL query against the remote DuckDB warehouse:

dango remote query "SELECT count(*) FROM stripe.charges"

dango remote query "SELECT * FROM hubspot.contacts LIMIT 10" --timeout 120

The query runs in read-only mode — INSERT, UPDATE, DELETE, and other write operations are rejected by DuckDB's access_mode=read_only setting.

Deployment History¶

View a log of all deployments to the server:

dango remote history

# Show last 20 entries
dango remote history --limit 20

Output columns:

Time                 Commit    Branch  Deployer       Duration  Status
2026-05-15 14:30:00  a1b2c3d4  main    deploy@local   45s       OK
2026-05-14 10:15:00  e5f6g7h8  main    deploy@local   1m 12s    OK
2026-05-13 16:45:00  i9j0k1l2  main    deploy@local   38s       FAIL

Recovery Commands¶

When things go wrong, these commands fix common issues without SSH access:

Repair¶

dango remote repair

Diagnoses and fixes common deployment issues: checks disk space, RAM, DNS resolution, restarts services, re-runs Metabase setup if metabase.yml is missing, and triggers a Metabase schema scan. Run this first when something isn't working.

Reset Metabase¶

dango remote reset-metabase

Resets Metabase to a fresh state when SSO breaks or the H2 database corrupts. Stops Metabase, removes its Docker volume, restarts it, and lets dango-web re-run Metabase setup on next startup. Does not affect your warehouse data — only Metabase's internal state (saved questions, dashboards) is lost. Re-import with dango metabase load after reset.

Remote User Management¶

Manage web UI user accounts on the server. These commands run remotely — they modify the authentication database on the server, not locally.

Add a User¶

dango remote auth add-user

Prompts for email and password interactively.

List Users¶

dango remote auth list-users

Shows all registered users with their email, role, and creation date.

Remove a User¶

dango remote auth remove-user

Prompts to select a user for removal.

Reset Password¶

dango remote auth reset-password

Prompts to select a user and enter a new password.

Troubleshooting¶

Deploy lock stuck¶

Error: Deploy lock is held by another process

If no other push is running, the lock may be stale from a previous push that was interrupted:

dango remote ssh

Then on the server:

rm /srv/dango/.dango/state/deploy.lock

SSH connection failed¶

Error: SSH connection failed

• Verify the server is running: check your cloud provider's console
• Check that port 22 is open in the firewall
• Verify the SSH key exists locally: ls ~/.ssh/dango_*
• Test connectivity manually: ssh -i ~/.ssh/dango_ed25519 root@<server-ip>

Push failed mid-deploy¶

If a push fails partway through (e.g., network interruption), the server may be in a partially updated state:

1. Check server status: dango remote status
2. If services are running, try pushing again: dango remote push --force
3. If services are down, roll back: dango remote rollback
4. Check logs for errors: dango remote logs

Query timeout¶

Error: Query timed out after 60 seconds

Increase the timeout for complex queries:

dango remote query "SELECT ..." --timeout 300

If queries consistently time out, consider resizing the server for more CPU and RAM.

Git guardrails blocking push¶

Warning: You have uncommitted changes

Either commit your changes or override:

# Commit first (recommended)
git add -A && git commit -m "Update models"
dango remote push

# Or override
dango remote push --allow-dirty --allow-branch

Next Steps¶

• Environment Variables — manage secrets on the server
• Backups — configure automated backups and restore
• Server Operations — upgrade, resize, and migrate
• Destroy & Cleanup — tear down a deployment