Installation & System Requirements
The product is one pre-built, multi-arch container image, UI, API, and migrations baked in. Beyond an OCI runtime there is nothing to compile or install on the host. Everything below sizes and places that single image.
Sizing
The app process is stateless (all durable state is in the metadata Postgres), so horizontal scale is linear, add replicas behind a load balancer. Per-replica floor and a sane baseline:
| Resource | Minimum | Recommended | Notes |
|---|---|---|---|
| vCPU | 2 | 4 | Concurrency-bound; scale out replicas before scaling up. |
| RAM | 2 GB | 4 GB | Headroom is dominated by large result sets and concurrent sessions. |
| Disk (app) | 1 GB | 5 GB | Image is ~250-400 MB; the rest is metadata Postgres growth. |
| Metadata Postgres | 13 | 16 | Bundled for evaluation; externalize to managed/HA Postgres for production. |
Tooling floors: Docker Engine 20.10+ / Compose 2.0+ for the Compose path; Kubernetes 1.24+ / Helm 3.10+ for the Helm path.
Platform matrix
| Dimension | Supported |
|---|---|
| Image architecture | linux/amd64, linux/arm64 (Graviton, Apple silicon) |
| Container runtimes | Docker Engine, Podman, containerd |
| Orchestration | Kubernetes (EKS, AKS, GKE, OpenShift, k3s, on-prem), Compose, Swarm, ECS Fargate, Azure Container Apps, Cloud Run, Fly.io, Railway |
| Host OS | Linux; macOS and Windows Server (Linux containers) for dev |
| Client | Current Chromium, Firefox, and Safari. WebSockets required for live notifications. |
Network posture
The deployment runs entirely inside your perimeter, no inbound internet and no outbound call to Simcha are required. License validation is fully offline. The only outbound egress the app ever needs is to systems you explicitly integrate:
- Target databases, reached over their native protocols from the app's network.
- Source control / object storage, only when repo/storage sync is configured.
- Identity provider, only when SSO federation is enabled.
Two listeners are exposed by the app (UI and API); the metadata Postgres port stays internal to the deployment. Ports are configurable, see the Configuration Reference.
Obtaining the image
docker pull simchasolutions/db-studio:1.0.1The delivery bundle (docker-compose.yml, .env.example, helm/) and the license key are provided separately.
Air-gapped installs
With no registry reachable, request the image as a tarball and side-load it, identical artifact, no build step:
docker load -i simcha-db-studio-<version>.tarNothing else about an air-gapped deployment differs, license activation and all core function are already network-independent.
Deployment paths
License activation
First access presents activation. The key (SDB-<base64url-payload>.<base64url-signature>) is RSA-verified against the public key baked into the build, tier and seat entitlements resolve locally with no network call. Activation state persists in the metadata store across restarts.
Upgrades
Migrations are additive and idempotent (guarded IF NOT EXISTS), the app adds tables/columns and never drops existing data. Back up the metadata database before every upgrade regardless.
- Compose:
docker compose pull app && docker compose up -d app, migrations run on boot. - Helm:
helm upgrade dbstudio ./helm --set image.tag=1.0.2 -f overrides.yaml, the pre-upgrade migration Job gates the rollout.
Uninstall
- Compose:
docker compose down -vremoves containers and volumes, including the metadata DB. Data is destroyed. - Helm:
helm uninstall dbstudio -n dbstudio; PVCs and the namespace persist until you delete them explicitly.
Support
- Troubleshooting for known failure modes.
- Logs on stdout:
docker compose logs -f app/kubectl logs -f deploy/dbstudio. - contactus@simchasolutions.com with logs and environment detail.