webgate

Self-hosted web app for remote server management — SSH terminal, SFTP file browser, server registry, all in your browser. Host keys are verified, credentials are encrypted at rest, and an admin configures the whole thing from inside the app. A modern Python replacement that combines the best of webssh and filebrowser into a single tool. It borrows FileZilla's workflow — a site list, quick connect, a path bar — without copying its chrome: a dense, keyboard-first console meant to sit behind a terminal for hours.

🎮 Try it live: webgate-demo.fly.dev — login demo / demo (read-only sandbox, resets hourly)

📖 Docs: kalexnolasco.github.io/webgate

Quick start

export WEBGATE_SECRET_KEY=$(openssl rand -hex 32)
docker compose up -d
# open http://localhost:8443/ — login: admin / admin

That's it. The first login forces a password change. Add servers from the Site Manager, click SSH or SFTP to connect.

For a richer dev environment with a sandboxed SSH target pre-baked: docker compose -f compose.dev.yml up --build.

Upgrading

docker compose pull && docker compose up -d

The schema migrates itself on boot — no migration command, no tool to learn. Changes are additive only, so rolling back to an older image works if you need it. Back up first (cp webgate.db webgate.db.bak, or Admin → Backup & restore). Full guide: Upgrading.

On v0.x? That line is legacy and unsupported — see Legacy versions before upgrading.

🧪 Want to try every feature end-to-end? A ready-to-run playground brings up webgate plus an LDAP server, a public SSH host, a private SSH host only reachable via a bastion, and an HTTP echo for webhooks:

docker compose -f compose.playground.yml up -d --build

Full walkthrough with screenshots: docs/LOCAL_TESTING.md.

Why webgate?

Managing remote servers means juggling SSH clients, SFTP tools, credentials and VPN configs across your team. In many real-world setups direct SSH access to every server isn't possible — only HTTP(S) reaches the gateway.

The problem

flowchart TB
    subgraph internet ["Internet"]
        YOU["Your Team"]
    end
    subgraph firewall ["Client Firewall"]
        GW["Gateway Server<br/>(HTTP only)"]
        subgraph internal ["Internal Network"]
            DB1[(PostgreSQL<br/>10.0.1.10)]
            DB2[(MySQL<br/>10.0.1.11)]
            APP1["App Server<br/>10.0.1.20"]
            APP2["App Server<br/>10.0.1.21"]
            WORKER["Worker<br/>10.0.1.30"]
            REDIS["Redis<br/>10.0.1.40"]
        end
    end
    YOU -- "HTTPS :443" --> GW
    GW -. "SSH :22" .-> DB1
    GW -. "SSH :22" .-> DB2
    GW -. "SSH :22" .-> APP1
    GW -. "SSH :22" .-> APP2
    GW -. "SSH :22" .-> WORKER
    GW -. "SSH :22" .-> REDIS
    style internet fill:none,stroke:#4a90d9,stroke-width:2px
    style firewall fill:none,stroke:#ff9800,stroke-width:2px
    style internal fill:none,stroke:#5cb85c,stroke-width:2px
    style GW fill:#ffcc02,stroke:#e6a800,color:#333
    style YOU fill:#4a90d9,stroke:#2a6cb5,color:#fff

The solution

Deploy webgate on the gateway. Everyone gets browser-based SSH and SFTP to every internal server — no VPN, no scattered SSH keys, full audit trail.

flowchart TB
    subgraph internet ["Internet"]
        ENG1["Engineer 1<br/>(Browser)"]
        ENG2["Engineer 2<br/>(Browser)"]
        ENG3["Engineer 3<br/>(Browser)"]
    end
    subgraph firewall ["Client Firewall"]
        WG["webgate<br/>Gateway Server :443"]
        subgraph internal ["Internal Network"]
            DB1[(PostgreSQL)]
            APP1["App Server"]
            WORKER["Worker"]
            REDIS["Redis"]
        end
    end
    ENG1 -- "HTTPS" --> WG
    ENG2 -- "HTTPS" --> WG
    ENG3 -- "HTTPS" --> WG
    WG -- "SSH/SFTP" --> DB1
    WG -- "SSH/SFTP" --> APP1
    WG -- "SSH/SFTP" --> WORKER
    WG -- "SSH/SFTP" --> REDIS
    style internet fill:none,stroke:#4a90d9,stroke-width:2px
    style firewall fill:none,stroke:#ff9800,stroke-width:2px
    style internal fill:none,stroke:#5cb85c,stroke-width:2px
    style WG fill:#5cb85c,stroke:#449d44,color:#fff
    style ENG1 fill:#4a90d9,stroke:#2a6cb5,color:#fff
    style ENG2 fill:#4a90d9,stroke:#2a6cb5,color:#fff
    style ENG3 fill:#4a90d9,stroke:#2a6cb5,color:#fff

Use cases

Features

Keyboard

Ctrl+Shift+P reaches the palette from inside a terminal too; plain Ctrl+P is deliberately left alone there so readline keeps previous-command.

Screenshots

Taken by the browser tests (tests/e2e) against a real webgate and a real SSH host, so they show the build those tests just drove and cannot drift into an interface that no longer exists.

Site Manager, terminal, SFTP, command palette

Left to right: the registry with live status dots and grouped servers; an SSH session opened through bastion-eu; the file browser with sortable columns, owner names and multi-select; Ctrl+P over every server and action.

Admin

Settings shows where each value comes from — this panel, a named environment variable, or the shipped default — and warns in red where a choice loosens something. AI agent is off until a provider is configured. Branding white-labels the deployment for every user.

Light theme, and the sign-in screen

Architecture

Project layout

src/webgate/
├── __main__.py          uvicorn launcher
├── app.py               FastAPI factory, lifespan, middleware
├── config.py            boot settings (env only); the rest live in the admin panel
├── agent/               per-server AI chat: provider, tools, SFTP-only tools, cache
├── audit/               immutable action log
├── auth/                JWT + bcrypt, 2FA TOTP, API keys, LDAP, user management
├── backup/              full-state export/import, passphrase-encrypted
├── branding/            white-label store: name, logo, colours, favicon
├── db/                  async engine + additive, append-only migrations
├── files/
│   ├── sftp_service.py  SFTP operations, chunked reads, ZIP builders
│   ├── pool.py          connection reuse, 300 s TTL
│   ├── limits.py        per-request transfer budget
│   └── routes.py        REST endpoints
├── recordings/          asciinema cast v2 writer + browser replay
├── runtime_config/
│   ├── registry.py      every setting an admin may change, with its validation
│   ├── store.py         key/value rows, encrypted secrets, in-process snapshot
│   └── routes.py        /api/settings
├── servers/
│   ├── hostkeys.py      trust-on-first-use pinning and verification
│   ├── monitor.py       leader-elected status sweep
│   ├── crypto.py        Fernet credential encryption
│   └── service.py       registry CRUD, jump-host resolution
├── snippets/            per-user command library
├── terminal/
│   ├── ssh_session.py   asyncssh wrapper, optional jump tunnel
│   ├── shared.py        SharedSession registry: 1 PTY ↔ N WebSockets, idle watchdog
│   ├── ws_handler.py    input multiplex / output broadcast
│   └── routes.py        WS endpoints + share-token mint/revoke
├── webhooks/            HMAC-signed event dispatcher
└── static/index.html    single-file frontend (Alpine.js + xterm.js + CodeMirror)

What talks to what

Browsers speak HTTPS and WebSocket to one address. Everything behind it — SSH, SFTP, LDAP, the model provider — is reached from the gateway, outbound. That is the point: in most deployments the servers have no route to the internet and the people have no route to the servers.

flowchart LR
  subgraph people["People"]
    B["Browser<br/>Alpine.js + xterm.js"]
  end

  subgraph gw["Gateway — the only host with both routes"]
    W["webgate<br/>FastAPI :8443"]
    DB[("SQLite or PostgreSQL<br/>credentials encrypted<br/>with Fernet")]
  end

  subgraph fleet["Internal network — no inbound internet"]
    BAS["Bastion"]
    S1["prod-web-01 :22"]
    S2["prod-db-primary :22"]
    S3["SFTP-only host"]
  end

  subgraph ext["Outbound, optional"]
    LD["LDAP / AD"]
    AI["Ollama or OpenRouter"]
    WH["Webhook receivers"]
  end

  B -->|"HTTPS + WebSocket"| W
  W --- DB
  W -->|"SSH / SFTP"| BAS
  BAS -.->|"tunnel"| S1
  BAS -.->|"tunnel"| S2
  W -->|"SFTP only"| S3
  W -->|"bind + search"| LD
  W -->|"chat completions"| AI
  W -->|"HMAC-signed POST"| WH

Only the gateway needs a route to the model provider — inspected hosts never do, because the agent reaches them over SSH from here. Nothing is installed on the targets: a server only has to accept SSH, and some only accept SFTP.

📐 Full architecture, with five diagrams — module map, the SSH session including the part that refuses, multi-instance topology, and how a setting resolves: docs/architecture.md (rendered).

Four constraints that decided the rest

1. The gateway is the credential store. It is why host keys are verified before authentication, why the Fernet key stays in the environment, and why the agent's tools are read-only.
2. Workers are interchangeable. Nothing durable lives in memory or on a worker's disk. What stays local — pooled connections, open PTYs — is reconstructible and expected to be lost.
3. Migrations are additive, append-only, idempotent. No column is ever dropped or retyped, so an older release ignores what it does not know and a rollback is safe. A test enforces it.
4. The frontend has no build step. One HTML file. There is no compiled asset that can drift from the source it came from.

Jump host (bastion) chaining

When a server has jump_via_id set, webgate opens the SSH connection to the bastion first and tunnels the target connection through it. Same chain is used for the SFTP browser. No VPN required, only outbound SSH from the gateway to the bastion.

flowchart LR
    B["Browser"]
    WG["webgate"]
    BAST["bastion<br/>10.0.0.1"]
    INT["internal-app<br/>10.0.1.50"]
    B -- "HTTPS / WSS" --> WG
    WG -- "SSH" --> BAST
    BAST -- "SSH (tunneled)" --> INT
    style B fill:#4a90d9,stroke:#2a6cb5,color:#fff
    style WG fill:#5cb85c,stroke:#449d44,color:#fff
    style BAST fill:#ffcc02,stroke:#e6a800,color:#333
    style INT fill:#b25e00,stroke:#ff9800,color:#fff

Shared terminal session

The owner's terminal is registered with a SharedSession. When the owner clicks Share, a token is minted and any joiner with the URL attaches a second WebSocket. There's still one SSH PTY — output is broadcast to all clients, input from any RW client is multiplexed into the same stdin.

flowchart LR
    O["Owner WS"]
    J1["Joiner WS (rw)"]
    J2["Joiner WS (ro)"]
    SS["SharedSession"]
    PTY["asyncssh PTY"]
    REMOTE["Remote SSH server"]
    REC["CastRecorder<br/>(if recording on)"]

    O -- "input" --> SS
    J1 -- "input" --> SS
    J2 -. "no input" .-> SS
    SS -- "write stdin" --> PTY
    PTY -- "stdout" --> SS
    SS -- "broadcast" --> O
    SS -- "broadcast" --> J1
    SS -- "broadcast" --> J2
    SS -. "tee" .-> REC
    PTY <--> REMOTE

    style SS fill:#5cb85c,stroke:#449d44,color:#fff
    style PTY fill:#ffcc02,stroke:#e6a800,color:#333
    style REC fill:#a78bfa,stroke:#7c3aed,color:#fff

Access model — groups, tags, LDAP

Three concepts, easy to mix up. Here's how they fit together:

With LDAP, the admin still controls which group names exist by typing them when registering each server. LDAP only populates the user side of the equation:

flowchart LR
    subgraph LDAP
        L1["alice ∈ cn=devs"]
        L2["alice ∈ cn=admins"]
    end
    subgraph MAP["Group mapping<br/>Admin &rarr; Settings &rarr; LDAP"]
        M["{<br/>  &quot;devs&quot;: &quot;production&quot;,<br/>  &quot;sre&quot;: &quot;all&quot;<br/>}"]
    end
    subgraph User
        U["alice.allowed_groups<br/>= [&quot;production&quot;]"]
    end
    subgraph Servers
        S1["app-1<br/>group=production ✅"]
        S2["app-2<br/>group=staging ❌"]
        S3["db-1<br/>group=production ✅"]
    end
    L1 -- mapped --> M
    L2 -. ignored<br/>(not in map) .-> M
    M --> U
    U --> S1
    U --> S3

Key rules:

• LDAP does not create groups on the webgate side. The right-hand value of the group mapping must match exactly what you typed in Server.group.
• An LDAP group that isn't in the map is silently ignored.
• Admin groups is independent of the map: any membership in those groups grants admin (and admins see all servers).
• Tags are never used for access control, only for filtering / search in the UI.

LDAP authentication

Search-then-bind: webgate binds as the service account, finds the user DN, re-binds as the user with their password to verify credentials, then enumerates LDAP groups and maps them to webgate groups (and admin status).

sequenceDiagram
    participant Browser
    participant webgate
    participant LDAP

    Browser->>webgate: POST /api/auth/login (alice, ****)
    webgate->>webgate: try local password (miss)
    webgate->>LDAP: bind(svc-DN, svc-password)
    LDAP-->>webgate: ok
    webgate->>LDAP: search(uid=alice) under user_base
    LDAP-->>webgate: dn=uid=alice,ou=people,...
    webgate->>LDAP: re-bind(user-DN, user-password)
    LDAP-->>webgate: ok ✅
    webgate->>LDAP: search(member=user-DN) under group_base
    LDAP-->>webgate: [devs, admins]
    webgate->>webgate: map → allowed_groups, is_admin
    webgate->>webgate: upsert local User row
    webgate-->>Browser: JWT

Configuration

Most settings live in Admin → Settings, in the app. They take effect without a restart and apply to every instance of the gateway, so changing a monitor interval or pointing at a different LDAP server is not a redeploy.

The rest are environment variables prefixed with WEBGATE_, because they are read before webgate can serve the request that would change them — or because letting the panel change them would be a way to lock yourself out.

In the admin panel

Each one shows where its current value comes from — this panel, an environment variable, or the shipped default — and can be reset back to the environment.

An environment variable still seeds a fresh install, which is what makes automated provisioning work; once a value is set in the panel, the panel wins. To keep configuration entirely in your manifests, set WEBGATE_CONFIG_LOCKED=true and the panel becomes read-only.

Environment only

Every panel setting also accepts its WEBGATE_-prefixed variable as the initial value: WEBGATE_MONITOR_INTERVAL, WEBGATE_LDAP_URL, and so on.

LDAP / Active Directory

The same fields, for seeding them from the environment:

Deployment

Production with Docker

export WEBGATE_SECRET_KEY=$(openssl rand -hex 32)
docker compose up -d

The default compose.yml pulls kalexnolasco/webgate:latest, persists state in a named volume, and lists the optional features as commented env vars you can opt into.

Behind a reverse proxy with TLS

Caddy (simplest)

# add to compose.yml
caddy:
  image: caddy:2-alpine
  restart: unless-stopped
  ports: ["443:443", "80:80"]
  volumes:
    - ./Caddyfile:/etc/caddy/Caddyfile
    - caddy-data:/data

# Caddyfile
webgate.example.com {
    reverse_proxy webgate:8443
}

nginx (sub-path /webgate/)

Set WEBGATE_ROOT_PATH=/webgate on the container, then:

server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # WebSocket — must come before the generic location
    location /webgate/api/ws/ {
        proxy_pass http://127.0.0.1:8443;
        proxy_http_version 1.1;
        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host       $host;
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
    }
    location /webgate/ {
        proxy_pass http://127.0.0.1:8443;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Prefix /webgate;
        client_max_body_size 100m;
    }
}

Apache 2.4 (sub-path /webgate/)

# Required modules: proxy proxy_http proxy_wstunnel headers rewrite ssl
RewriteEngine On
RewriteRule ^/webgate$ /webgate/ [R=301,L]

ProxyPreserveHost On
RequestHeader set X-Forwarded-Proto  "https"
RequestHeader set X-Forwarded-Prefix "/webgate"

ProxyPass        /webgate/api/ws/  ws://127.0.0.1:8443/webgate/api/ws/
ProxyPassReverse /webgate/api/ws/  ws://127.0.0.1:8443/webgate/api/ws/
ProxyPass        /webgate/  http://127.0.0.1:8443/webgate/
ProxyPassReverse /webgate/  http://127.0.0.1:8443/webgate/

⚠️ The proxy must forward the prefix unchanged — webgate handles /webgate/api/... natively, do not strip it.

Traefik (Docker labels)

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.webgate.rule=Host(`example.com`) && PathPrefix(`/webgate`)"
  - "traefik.http.routers.webgate.entrypoints=websecure"
  - "traefik.http.routers.webgate.tls=true"
  - "traefik.http.services.webgate.loadbalancer.server.port=8443"

Multi-instance HA (N replicas + PostgreSQL)

Run multiple webgate workers behind a load balancer, all sharing one Postgres database. Only one worker probes server connectivity at a time (leader election via a singleton lease row); the rest handle REST/WS traffic normally.

flowchart LR
    U["Users"]
    LB["Load balancer<br/>(sticky: ip_hash)"]
    W1["webgate #1<br/>(leader)"]
    W2["webgate #2<br/>(follower)"]
    W3["webgate #3<br/>(follower)"]
    PG[(PostgreSQL<br/>shared state)]
    LEASE[["monitor_lease<br/>(singleton row)"]]
    U --> LB
    LB --> W1
    LB --> W2
    LB --> W3
    W1 --> PG
    W2 --> PG
    W3 --> PG
    W1 -- holds --> LEASE
    W2 -. watches .-> LEASE
    W3 -. watches .-> LEASE
    style LB fill:#ffcc02,stroke:#e6a800,color:#333
    style W1 fill:#5cb85c,stroke:#449d44,color:#fff
    style W2 fill:#2a6cb5,stroke:#4a90d9,color:#fff
    style W3 fill:#2a6cb5,stroke:#4a90d9,color:#fff
    style PG fill:#b25e00,stroke:#ff9800,color:#fff

Reference stack:

export WEBGATE_SECRET_KEY=$(openssl rand -hex 32)
docker compose -f compose.ha.yml up -d
curl -s http://localhost:8443/api/health   # shows instance_id + monitor_role

compose.ha.yml spins up 2 webgate replicas + Postgres + nginx with ip_hash sticky sessions. On leader loss, the lease expires within 90 seconds and another replica picks it up automatically.

Known limitation: live shared-terminal sessions still need owner and joiner on the same worker. Sticky sessions mitigate it for same-browser joins; true cross-worker fan-out requires a Redis pub/sub layer (not yet implemented).

Backup, restore and migration

Admin → Backup & restore, or the API directly. One file carries servers, users, groups, webhooks and API keys.

# Back up, credentials included, encrypted under a passphrase you choose
curl -X POST https://gate.example.com/api/backup/export \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"passphrase":"choose-a-strong-one","include_audit":false}' \
  -o webgate-backup.json

# Restore onto another instance
curl -X POST https://new-gate.example.com/api/backup/restore \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d "{\"passphrase\":\"choose-a-strong-one\",\"mode\":\"merge\",\"data\":$(cat webgate-backup.json)}"

Why the passphrase matters. Server credentials are encrypted with a key derived from WEBGATE_SECRET_KEY, so the stored ciphertext is meaningless on an instance with a different key. A backup therefore decrypts them, and the restore re-encrypts with the target's own key — which is what makes the file portable, and also what makes it a credential dump. Supplying a passphrase seals the payload with PBKDF2-HMAC-SHA256 (480k iterations) + Fernet. Without a passphrase the backup is metadata only and you would re-enter every credential by hand.

A fresh instance blocks writes until the seeded admin password is changed, so change it before restoring into one.

Public read-only demo (Fly.io)

The repo includes Dockerfile.demo (webgate + sandboxed sshd via supervisord) and fly.toml. Deploy:

flyctl launch --no-deploy --copy-config
flyctl secrets set WEBGATE_SECRET_KEY=$(openssl rand -hex 32)
flyctl volumes create webgate_demo_data --size 1 --region cdg
flyctl deploy

The demo middleware blocks all writes on /api/* (login, terminal share and totp/verify whitelisted), so anyone hitting the URL can browse the seeded bastion + internal-app pair without poking holes in your infra. The official live demo at https://webgate-demo.fly.dev runs exactly this.

API reference

Full OpenAPI is auto-generated at /docs (Swagger UI) and /redoc.

Development

uv sync --all-extras --dev          # install
uv run python -m webgate            # run
uv run uvicorn webgate.app:create_app --factory --reload --host 0.0.0.0 --port 8443

# tests
uv run pytest tests/ -v
uv run pytest tests/ -v --cov=webgate

# browser tests: a real browser against a real webgate and a real SSH host.
# Opt-in, because they start both. They also take the screenshots in the docs.
uv run playwright install chromium
uv run pytest tests/e2e -m e2e

# lint — clean, and expected to stay that way
uv run ruff check src/ tests/
uv run ruff format src/ tests/

# types — pyright runs in strict mode and does NOT pass yet (~100 findings,
# about 80 of them `reportUnknown*` where asyncssh and ldap3 ship no type
# information). Treat a change to that count as the signal, not zero.
uv run pyright src/

# build wheel
uv build

Every push runs the same checks in CI, plus a Docker build that has to start and answer, and a strict docs build. Cutting a release is one tag — see RELEASING.md for what that triggers and the one-time setup behind it.

Or use the dev compose with a sandboxed SSH target ready to register:

docker compose -f compose.dev.yml up --build
# Inside the UI register: hostname=ssh-demo  user=demo  password=demo

Tech stack

• Backend: Python 3.11+, FastAPI, uvicorn, asyncssh, SQLAlchemy 2 async, aiosqlite/asyncpg, Pydantic v2, slowapi, ldap3, pyotp, httpx
• Frontend: Alpine.js, xterm.js, CodeMirror 6, vanilla CSS (no build step)
• Storage: SQLite by default, PostgreSQL via WEBGATE_DB_URL. Credentials encrypted at rest with Fernet
• Recording: asciinema cast v2 (JSON Lines), replay via embedded asciinema-player from CDN
• Build/Dev: uv, ruff, pyright, pytest, Docker (multi-stage)

Security

• Single sign-on verifies the ID token properly: signature against the provider's published keys, plus issuer, audience, expiry and a per-sign-in nonce. The flow uses PKCE, its state lives in the database so it works across workers, and the session token is handed over as a one-time code rather than in a URL
• Host keys are verified — trust on first use. The first connection to a server records the key it presents; every connection after that is checked against it before authentication runs, so a mismatch sends nothing. Accepting a changed key is a deliberate, audited admin action. This covers the terminal, SFTP, the connection pool, the status monitor, the agent and jump hosts
• All SSH passwords and private keys are encrypted at rest with Fernet (key derived from WEBGATE_SECRET_KEY)
• The default secret key is refused. That key signs every session token and derives the credential encryption key, and its default is published in this repository — a deployment that never changed it will hand a valid admin token to anyone who asks. webgate now stops at startup rather than serving under it, unless it is bound to loopback only
• Passwords use bcrypt; sessions use JWT (HS256)
• 2FA TOTP available per user
• API keys for non-interactive auth (Authorization: Bearer wg_…)
• Rate limiting on auth endpoints (slowapi)
• Path traversal validation on every SFTP operation
• Per-server access control — admins can disable SSH or SFTP independently, restrict SFTP to allow-listed paths, mark SFTP read-only
• Group-based visibility — non-admin users only see servers in their assigned groups
• HMAC-signed webhooks so receivers can verify the payload came from your webgate
• Recommended: put webgate behind a TLS-terminating reverse proxy (Caddy/nginx/Traefik) in production

Requirements

• Python 3.11+ (or just Docker)
• 256 MB RAM minimum (512 MB recommended)
• ~100 MB disk for the image plus your data (DB + uploaded SSH keys + recordings)

Legacy versions

v2.x is the only supported line. Everything before it — v0.1 through v0.5.3 — is legacy: no fixes, no backports, and it is missing the security work v2 exists for.

If you are running v0.x, the thing to know is that every SSH and SFTP connection it makes runs with host key verification disabled. It authenticates to whatever answers on a server's address and hands it the stored credentials. That is fixed in v2.0.0, and it is the reason to move.

Upgrading from v0.x is the same command as any other upgrade — the schema migrates itself, additively, and your servers, users and credentials come across untouched:

docker compose pull && docker compose up -d

Two things change on first boot. Existing servers have no pinned host key, so the next connection to each one records what it presents and nothing breaks; from then on a changed key is refused. And WEBGATE_MAX_UPLOAD_SIZE and WEBGATE_SESSION_TIMEOUT, which v0.x accepted and ignored, now actually apply. Full detail: Upgrading.

There is no v1.x. The jump from v0.5.3 to v2.0.0 was deliberate: the release changed what the product is responsible for, and a minor bump would have undersold that.

Roadmap

See ROADMAP.md for the full plan and what's shipped per release.

License

MIT — see LICENSE.