Quickstart on one node
This runs every component at a single replica on a single node. There is no redundancy anywhere: losing the node loses the data. Postgres has no standby, Kafka has one broker at replication factor 1, and the object store has no erasure coding.
Use it for evaluation, training and upgrade rehearsals. For anything you depend on, follow Sizing a production install, which runs on three nodes.
What you get
A working instance you can sign in to, on one machine, without planning a cluster.
This is not a separate procedure. It is the same install as the rest of this documentation, with one extra values file per chart.
What you need
| One node | 12 vCPU, 32 GB RAM, 200 GB disk |
| Kubernetes | k3s |
| StorageClass | local-path, which k3s installs by default |
| Tools | The same list as Requirements |
| Credentials | The same two as Requirements. The relay is required here too |
How it differs from production
The kit ships an overlay per chart that reduces everything to one replica.
| Production | This quickstart | |
|---|---|---|
| Object store | 3 replicas, erasure coded, distributed | 1 replica, standalone mode, and a Deployment rather than a StatefulSet |
| Postgres | 3 instances | 1 instance, no replica pooler |
| Kafka | 3 brokers, replication factor 3 | 1 broker, every factor 1 |
| Application services | 2 or 3 replicas each | 1 each |
| Cache | Chart default | 256 MB, one thread |
| Storage | Your block StorageClass, 500 GiB per node minimum | local-path, about 65 GiB of volumes |
| Survives losing a node | Yes | No |
Only the replica pooler is disabled, because there is no replica to pool. Every service still
connects through core-pooler, exactly as in production, so the secrets that
make-db-secrets.sh composes are the same shape here.
The object store stops being a StatefulSet and becomes a Deployment of the same name. That is why the readiness checks in Install resolve the kind instead of naming it.
Volume claims from a previous multi-replica install are not reused. If you are converting an existing install, delete them first.
Run it
Follow the spine exactly as written, starting at Prepare the artifacts. Three commands change. Nothing else does.
| Spine step | On this install |
|---|---|
| Prepare the artifacts | Unchanged. Either method works, and the registry method is fewer steps |
| Install steps 1 and 2 | Unchanged. Same namespaces, same three secrets |
| Install steps 3, 4 and 7 | Add the overlay. See below |
| Install steps 5 and 6 | Unchanged. You still create the bucket, and you still run the secret script |
| Publish the endpoints | Unchanged. See the note on the address below |
| First sign-in and Verify the install | Unchanged |
Pass the overlay after the production values file, so it wins.
helm install g0s-infra $B/charts/gen0sec-infra-*.tgz -n gen0sec-system \
-f $B/values/gen0sec-infra-values-onprem.yaml \
-f $KIT/examples/single-node/infra-values.yaml
helm install g0s-data $B/charts/gen0sec-data-*.tgz -n gen0sec-system \
-f $B/values/gen0sec-data-values-onprem.yaml \
-f $KIT/examples/single-node/data-values.yaml
helm install g0s $B/charts/gen0sec-platform-*.tgz -n gen0sec \
-f $B/values/gen0sec-platform-values-onprem.yaml \
-f $KIT/examples/single-node/platform-values.yaml \
--set global.imageTag=$VERSION \
--timeout 20m
The wait gates after each one are the same as on Install. Read the files before you use them: each overlay carries comments explaining what it trades away.
The overlays set storageClass: local-path, which is the k3s default and exists on no other
distribution. Left as-is anywhere else, every PVC references a StorageClass that is not there and
stays Pending. helm install still reports success, and the only symptom is the wait gate above
timing out without naming a cause.
Set it to your own block StorageClass in all three places — rustfs.storageclass.name in
infra-values.yaml, and postgres.volume.storageClass plus kafka.storage.class in
data-values.yaml — or override them with a fourth -f layered last. Check before installing:
helm template ... | grep storageClassName # must show yours, never local-path
The address
Publish the endpoints is unchanged, including the requirement for a host. On k3s the bundled LoadBalancer implementation gives the ingress data plane the node's own address, so there is nothing further to provision.
For an evaluation, a name in /etc/hosts on the machine you browse from is enough. It has to be the
name you actually type in the browser, because the dashboard builds its sign-in URL from it.
In case your TLS termination does not happen on a higher level, configure Synapse Ingress to work
with cert-manager (see the
Kubernetes ingress reference). The shipped
ingress overlay sets externalScheme: https and configures no certificate at the ingress.
A single-node evaluation usually has none. Either provision a
certificate, or serve plain HTTP: set externalScheme to http in the ingress overlay and use an
http:// base URL in the sign-in and verify steps below.
First sign-in
Nothing is different here, and it is worth knowing before you get there: the dashboard makes you enroll multi-factor authentication and replace the seeded password before anything opens. See First sign-in.
Verify
Run the same checks as a production install, from Verify the install. The smoke test is the one that matters, because it proves the platform serves an agent rather than merely starting:
# Save the agent key you minted at first sign-in, then read it back below.
mkdir -p ~/.gen0sec
printf '%s' '<the agent key from the dashboard>' > ~/.gen0sec/agent-key
export GEN0SEC_BASE_URL=https://$ENTRYPOINT_HOST
export GEN0SEC_AGENT_KEY=$(cat ~/.gen0sec/agent-key)
$KIT/scripts/verify-deployment.sh
A single-node install that passes it is a good rehearsal for a real one. That is most of the value of building this.
Tearing it down
$KIT/scripts/uninstall.sh --yes
It asks you to type the cluster context name back before deleting anything, so it will not run unattended. See Uninstall.
When you are ready for production
Sizing a production install has the node counts, per-node capacity and storage figures. There is no in-place conversion from this install to a production one: build the production cluster separately.