Which shape to deploy

Three shapes, and the choice is not made on the number of users: it is made on what you accept to lose when a machine goes, and on how many organisations the gateway serves.

One gateway community meerkat its volume + one pod, one volume + no database beside it + one organisation docker-compose.yml values-ce-one-node.yaml One gateway Enterprise meerkat its volume + one pod, one volume + several organisations + directories, dev tunnel docker-compose.ee.yml values-ee-one-node.yaml Three gateways Enterprise meerkat meerkat meerkat PostgreSQL + three pods, no volume + one shared PostgreSQL + no-downtime updates stack.swarm.yml values-ee-cluster.yaml
What each shape holds, and the file that deploys it.

One gateway, community

One container, one volume, nothing beside it. The embedded store holds the routes, the accounts, the roles, the sealed vault and the certificates. That is the whole gateway for one organisation, free, production included.

What it does not do is survive the loss of its machine: a volume does not follow a container from one host to another. Back up the volume and you have backed up the gateway.

# Docker
curl -fsSLO https://meerkat.softwarity.dev/deploy/docker-compose.yml
MEERKAT_ADMIN_PASSWORD='choose-one' docker compose up -d

# Kubernetes
helm repo add meerkat https://meerkat.softwarity.dev/deploy
helm install meerkat meerkat/meerkat -f https://meerkat.softwarity.dev/deploy/values-ce-one-node.yaml \
  --set admin.password='choose-one'

One gateway, Enterprise

Same shape, Enterprise image: several organisations, the corporate directories, and the developer tunnel. That one listens on 22222, and it is one more port to publish where your developers reach it and nowhere else. It does not speak HTTP: it is SSH, and what the gateway checks there is the public key each developer deposited on their account. See Development mode.

The Enterprise image lives on a private registry, hence a pull secret:

kubectl create secret docker-registry ghcr \
  --docker-server=ghcr.io --docker-username=YOU --docker-password=TOKEN

helm install meerkat meerkat/meerkat -f https://meerkat.softwarity.dev/deploy/values-ee-one-node.yaml \
  --set admin.password='choose-one'

To try it first, the evaluation image installs the same shape with no pull secret: -f https://meerkat.softwarity.dev/deploy/values-eval-one-node.yaml.

Three gateways, Enterprise

What makes three pods ONE gateway is the database they share, and nothing else: the nodes never address each other. Sessions live there too, so there is no affinity to ask of the load balancer, and a rolling update takes nobody's session with it.

There is no volume any more: what the gateway knows is rows. But the vault's master key has to be the same on every pod, or a secret sealed by one is unreadable by the others.

kubectl create secret generic meerkat-state \
  --from-literal=database-url='postgres://meerkat:PASSWORD@postgres:5432/meerkat?sslmode=require' \
  --from-literal=vault-key="$(openssl rand -hex 32)"

helm install meerkat meerkat/meerkat -f https://meerkat.softwarity.dev/deploy/values-ee-cluster.yaml \
  --set admin.password='choose-one'

The same cluster on the evaluation image, to try it before buying it: -f https://meerkat.softwarity.dev/deploy/values-eval-cluster.yaml, with the same Secret.

On Swarm, the same shape deploys with the stack below. The three values are interpolated by Swarm at deploy time, from the shell that deploys: they are never in the file.

export MEERKAT_DATABASE_URL='postgres://meerkat:PASSWORD@postgres:5432/meerkat?sslmode=require'
export MEERKAT_VAULT_KEY="$(openssl rand -hex 32)"   # once, then keep it
export MEERKAT_ADMIN_PASSWORD='choose-one'
docker stack deploy -c stack.swarm.yml meerkat

The stack also runs a read-only proxy of the Docker socket on every node (docker-proxy, mode: global), on a network only the gateway joins. It lets reads through and refuses every write. Through it the route editor offers the Swarm services, and the Routes list shows each target's ready replicas and image, from the events of every node: a container's events come only from the node it runs on.

Three pods on the embedded store are three gateways: three sets of routes, three sets of accounts, and a console showing whichever one your request reached. The chart refuses to render that shape and says what to set instead.

The files

These are the repository's own, copied here on every publication of the site: what you download is what the released version deploys.

File For
index.yaml The Helm repository: helm repo add meerkat https://meerkat.softwarity.dev/deploy. It lists every released version: helm install takes the newest, and --version 1.9.0 (or a version pinned in Argo CD, Flux or Terraform) stays installable after the next release
meerkat-chart.tgz The Helm chart, installed as it is
values-ce-one-node.yaml One community gateway on its volume
values-ee-one-node.yaml One Enterprise gateway, developer tunnel open
values-ee-cluster.yaml Three Enterprise gateways on a shared PostgreSQL
values-eval-one-node.yaml One gateway on the evaluation image, developer tunnel open
values-eval-cluster.yaml Three gateways on the evaluation image, on a shared PostgreSQL
docker-compose.yml One community gateway, one command
docker-compose.ee.yml One Enterprise gateway with the tunnel
stack.swarm.yml Three gateways on Docker Swarm

The repository distributes the chart, not the images: the cluster pulls those itself, from the registry the values name. There is one chart for both editions, and the edition is the image:

Every file is commented line by line: what a variable does, and what it costs to forget it. The detail of each variable is on One gateway, and the Kubernetes manifests written out in full are on Kubernetes cluster.