Install with Helm

The chart deploys the Depotex server (a StatefulSet) and web app (a Deployment), with PostgreSQL, Redis and MinIO built in for a quick start, each of which can be switched off for a managed service. It never creates secrets: a script creates them beforehand and writes the installation's keys to a file you keep. This page walks through an installation from an empty namespace to a running, licensed cluster; Docker & Kubernetes is the reference for the images, network policies and monitoring.

1. Requirements

Resource requests in the chart are a small starting point (server 250m CPU and 512 MiB, limit 2 GiB; web app 100m and 256 MiB, limit 1 GiB). See Plan an installation before production.

2. 1. Prepare values

Start from one of these. Everything not set keeps the chart's default (the full list is under Values reference below).

Evaluation: built-in PostgreSQL, Redis and MinIO, one server.

# my-values.yaml
publicUrl: https://depotex.example.com
backend:
  image: { repository: registry.example.com/depotex/depotex-backend, tag: "<version>" }
frontend:
  image: { repository: registry.example.com/depotex/depotex-frontend, tag: "<version>" }
ingress:
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
    cert-manager.io/cluster-issuer: letsencrypt
  tls: { enabled: true }

Production: managed PostgreSQL, Redis and S3, three servers (shipped as values-external.yaml).

publicUrl: https://depotex.example.com
backend:
  replicas: 3          # cluster mode: Pro license and Redis
  tmpSize: 20Gi        # room to stage backups
  resources:
    requests: { cpu: "2", memory: 4Gi }
    limits: { memory: 8Gi }
  metrics: { enabled: true, serviceMonitor: { enabled: true } }
postgresql: { enabled: false }
redis: { enabled: false }
minio: { enabled: false }
storage:
  backend: s3
  bucket: my-depotex-artifacts
  s3: { region: eu-west-1 }
ingress:
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
  tls: { enabled: true, secretName: depotex-tls }
networkPolicy:
  ingressNamespaceSelector:
    kubernetes.io/metadata.name: ingress-nginx

Air-gapped: set global.imageRegistry to your mirror (prepended to every image, the built-in services' too) and global.imagePullSecrets. The server needs no internet access for itself; proxy repositories need their upstreams, which can be another Depotex (see Upstreams). Set networkPolicy.backendInternetEgress: false and list what it may reach in networkPolicy.extraEgress.

3. 2. Create the secrets

kubectl create namespace depotex
deploy/helm/prime-secrets.sh init -n depotex -r depotex \
  --public-url https://depotex.example.com

The script generates every key and password, creates the Secrets <release>-app and <release>-infra in the namespace, and writes depotex-<namespace>-<release>-install-keys.txt, readable only by you. Options:

4. 3. Install

helm install depotex deploy/helm/depotex -n depotex -f my-values.yaml
kubectl -n depotex get pods -w

Pods wait in CreateContainerConfigError until the secrets exist. The server's init step waits for the built-in database. Without a license yet, the server starts in setup mode. helm status depotex -n depotex prints the next steps.

5. 4. License it

deploy/helm/prime-secrets.sh installation-id -n depotex -r depotex
# request a license for that ID, then:
deploy/helm/prime-secrets.sh license license.json -n depotex -r depotex

The installation ID is printed and recorded in the keys file. Send it to Vectored through vectored.dev/#contact or support@vectored.dev (see Get a license); the second command stores the license you receive in the app secret.

6. First-boot setup

Unattended setup builds the setup file from the chart: the administrator from setup.admin.email and setup.admin.name with ADMIN_PASSWORD from the secret, the database, Redis and storage from the values and secrets.

helm upgrade depotex deploy/helm/depotex -n depotex -f my-values.yaml
kubectl -n depotex logs -f depotex-backend-0

When the log shows the server running in normal mode, sign in at publicUrl as the administrator with the password from the keys file. Then set setup.mode: none in your values and upgrade once more, so the server stops receiving the setup key.

7. 5. Check the installation

• kubectl -n depotex get pods,pvc,ingress: every pod Running and Ready, every claim Bound.
• Open Settings → Advanced → System check (Pro): database, Redis, storage, email, live updates and each server's health. A Live updates warning means the ingress isn't sending /api/ws to the server (the chart's ingress does this by default).
• Open the ? menu → About: the version and which server answered.
• Push and pull one package through a test repository (see Supported formats).

8. Values reference

9. Scale to a cluster

1. Check the license — Pro or higher, with enough servers (Settings → Application → Licensing).
2. Use Redis and shared storage — Built-in or managed Redis, and S3, MinIO, Azure or a ReadWriteMany volume. Local disk per pod doesn't work for a cluster.
3. Size the database — Each server opens up to pool_max_conns connections: keep servers × pool_max_conns under PostgreSQL's max_connections. See Database connections.
4. Scale — Set backend.replicas and helm upgrade. Pods start one after another and join the cluster; Settings → Clustering lists them.

Scaling down: lower backend.replicas. A removed pod shuts down cleanly and shows as left; it drops off the list after a day.

10. Upgrade

1. Read the release notes — The changelog and security advisories.
2. Back up — Run a backup in Settings → Backups and check it finished.
3. Upgrade — Push the new images, set their tags, and helm upgrade depotex deploy/helm/depotex -n depotex -f my-values.yaml.
4. Watch — kubectl -n depotex rollout status statefulset/depotex-backend. Server pods restart one at a time; database migrations run once, on the first new server, while the others keep serving.
5. Check — System check, the About dialog's version, and a test download.

See Upgrades & maintenance for what happens during a rolling upgrade and how to roll back.

11. Uninstall

helm uninstall depotex -n depotex

• Removes the pods, services and ingress. The server pods' PersistentVolumeClaims, the built-in services' volumes and the secrets prime-secrets.sh created are kept: delete them yourself when you mean to throw the installation away (kubectl -n depotex delete pvc,secret -l app.kubernetes.io/instance=depotex, after checking what that selects).
• Artifacts in external storage (S3, Azure, an external MinIO) are never touched.
• Re-installing with the same release name and the kept secrets and volumes brings the same installation back.

12. Troubleshooting

Still stuck? Collect the details in Support and contact us.