Below you'll find an overview of the requirements for installing Garden Enterprise. Some sections will link to more detailed and use case specific guides.
The Garden Enterprise License will be delivered to you prior to the installation. It is then uploaded via the Replicated admin console, a web application that runs on localhost, during the initial set up.
Garden Enterprise runs in a Kubernetes cluster and is installed via the kots kubectl plugin. The container images for the system services are pulled from a private registry that’s set up automatically during the installation process.
- Must be version 1.16 or higher.
- Should generally have at least 3 worker nodes, minimum 4 vCPUs and 16GB RAM each. The ideal size and number of nodes depends on whether Garden Enterprise is used to run workflows or not, and if so, how many concurrent workflows are expected to be running at a given time.
- When using workflows, it’s advisable to raise the node size by 2-4x relative to the minimum size. See below for a note on workflow runners’ resource usage. Ideally, use auto-scaling on the worker nodes to handle load bursts if you expect to be running a large number of concurrent workflows concurrent workflows.
- Should have 20 GB of persistent storage.
The workflow runners are only used if Garden Enterprise is used to run workflows on VCS events. They are ephemeral pods that are spun up on VCS events, and that run workflows via Garden Core. These pods are isolated in their own namespace with limited permissions.
Note that several workflow runners can run at the same time (due to multiple inbound VCS events) and resource usage depends on the size of the project in question.
Garden Enterprise requires access to a PostgreSQL database. The database:
- Must run PostgreSQL version 11 or higher.
- Must be accessible from the Garden Enterprise API service.
- Should have at least a 40GB storage capacity.
- Should have at least 1 vCPU and 2 GB RAM.
- Must have the
The bulk of database operations are caused by events and log entries that are streamed from Garden Core. This happens when:
- A logged in user runs a Garden command
- Garden is run from CI where a personal access token has been set
- A workflow runner runs a workflow when triggered by VCS events
Therefore, database load is mostly determined by Garden Core usage from authenticated actors.
We generally recommend a managed cloud service where possible, e.g. AWS’ RDS, GCP’s Cloud SQL or Azure’s Database for PostgreSQL.
Garden Enterprise bundles Vault by default and the following only applies for customers that want to manage their own Vault instances.
If you prefer to manage your own Vault, the Vault server instance (or instances):
You will need to set up a load balancer or an ingress controller for your Garden Enterprise cluster and point a DNS record to it. The connection must be over HTTPs and you must have the hostname at hand during installation.
In general, there's a single entrypoint to Garden Enterprise, but you can optionally expose some of the monitoring services as well.
Garden Enterprise connects to your VCS provider so that can you import your Garden projects. We currently support GitHub (.com or Enterprise) and GitLab (.com or self-managed). Garden Enterprise also uses your VCS provider as an authentication provider. Other SSO implementations are possible but evaluated on a case-by-case basis. Furthermore, GitHub or GitLab can be optionally used to enable Garden Enterprise to run workflows on VCS events.
During the installation you will need to provide a public/private key pair. This is used for signing JSON Web Tokens and authenticating against Vault instance.
You can use the following command to generate a self-signed public/private key pair:
openssl req -x509 -nodes -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
KOTS Kubectl Plugin
curl https://kots.io/install | bash
Before installing Garden Enterprise, we highly recommend that you look at our Environment Configuration guide. It contains a list of all the configuration options for Garden Enterprise and the values you need to have at hand during the installation (e.g. database host name, GitHub/GitLab IDs, etc).