Skip to main content

Overview

ToolJet is an open-source, low-code platform for building internal tools: a visual app builder with 50+ datasource connectors and the built-in ToolJet Database. This template deploys the ToolJet server — UI and API on port 3000 — backed by a PostgreSQL instance that holds both the application database and the ToolJet Database, with optional Redis for running more than one replica.

Architecture

  • ToolJet server — A standard HTTP workload serving the UI and REST API on port 3000. It runs its database migrations automatically on boot and scales horizontally through tooljet.replicas. PostgREST (which serves the ToolJet Database API) and a single-instance fallback Redis are bundled inside the official image, so no extra workloads are deployed for them.
  • PostgreSQL — The postgres template as a subchart. A single instance holds two databases, both created automatically on first boot: tooljet (apps, users, and encrypted datasource credentials) and tooljet_db (the ToolJet Database, served through the in-image PostgREST). ToolJet’s boot scripts also create a sample_db with sample data.
  • Redis + Sentinel (optional) — The redis template as a subchart, pinned to one data node and one sentinel. It carries the shared job queue and multiplayer coordination between replicas, and is required whenever tooljet.replicas is 2 or more.

What Gets Created

  • Standard ToolJet Workload — The ToolJet server on port 3000 ({release}-tooljet), with tooljet.replicas replicas and configurable CPU and memory.
  • Stateful PostgreSQL Workload — One PostgreSQL instance from the subchart, with its own volume set (10 GiB by default).
  • Redis and Sentinel Workloads (optional) — One Redis data node and one sentinel, created when redis.enabled is true.
  • Secret — A template-created dictionary secret ({release}-tooljet-db) holding the database username and password used to assemble ToolJet’s PG_*, TOOLJET_DB_*, and PGRST_DB_URI settings. Your prerequisite key secret is not created by the template — see Prerequisites.
  • Identity & Policy — An identity bound to the ToolJet workload, and a policy granting it reveal on exactly the secrets it reads: the database secret, your prerequisite key secret, and — when configured — the SMTP and Redis password secrets.
This template does not create a GVC. You must deploy it into an existing GVC.

Prerequisites

ToolJet reads its root-of-trust keys from a dictionary secret that you create before installing. The keys are never passed through values.
1

Create the key secret

Create a dictionary secret containing the three keys ToolJet requires, generated the same way upstream’s setup scripts generate them:
2

Point the template at it

Set secrets.name to the secret’s name (default my-tooljet-secrets). Secrets are org-level, so no GVC flag is involved.
3

Back up the keys

Store a copy of all three values somewhere safe, outside Control Plane.
Create the secret before installing. A missing secret pauses the deployment waiting on it — the install looks broken until the secret exists. SECRET_KEY_BASE and LOCKBOX_MASTER_KEY are write-once: rotating LOCKBOX_MASTER_KEY makes every datasource credential ToolJet has stored undecryptable.
For authenticated SMTP, you also need a second dictionary secret holding SMTP_USERNAME and SMTP_PASSWORD — see Email. Everything else works with the defaults. Once your key secret exists, install the template using your preferred method:

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

First Run

ToolJet ships no default account. The first person to open the endpoint completes the Super Admin onboarding and creates the initial workspace, so open the instance and claim it as soon as the workload reports ready.
1

Wait for the first boot to finish

The container waits for PostgreSQL, creates both databases, and runs all of its schema migrations before it starts serving. Expect roughly two minutes once the image is cached on the location, and noticeably longer on the very first pull — the ToolJet image is multi-gigabyte.
2

Open the endpoint

Browse to the canonical *.cpln.app endpoint of the {release}-tooljet workload and complete the Super Admin form.
3

Invite your team

Invitations are sent by email, so configure SMTP at install time if you plan to invite users.

Configuration

The default values.yaml for this template:

ToolJet Server

  • image — The official ToolJet LTS image.
  • replicas — Number of ToolJet replicas. Anything above 1 requires redis.enabled: true; the chart fails the render with a clear message otherwise.
  • host — The public base URL ToolJet advertises in links and redirects, including the https:// scheme. Leave it empty to derive it from the workload’s canonical endpoint; set it when you serve ToolJet on a custom domain.
  • resources — CPU and memory bounds for the ToolJet container.
Do not lower tooljet.resources.maxMemory below the default 4Gi. The image bakes a 4096 MB Node heap, and the first boot’s schema migrations are killed by the out-of-memory reaper at smaller limits, leaving the workload in a crash loop that never finishes migrating.

Databases

One PostgreSQL instance from the postgres subchart backs the whole deployment, and ToolJet’s boot scripts create the databases it needs: Change postgres.config.password before installing — it seeds the database on first boot and cannot be changed afterwards by editing values. postgres.volumeset.capacity sets the initial data volume size in GiB (minimum 10), and postgres.resources bounds the database container.
The ToolJet Database is a core part of ToolJet 3.x and cannot be turned off.

Scaling

tooljet.replicas sets how many ToolJet replicas run. With more than one replica, all replicas must share one Redis for the job queue and for multiplayer coordination in the app editor, so redis.enabled must be true — the single-instance Redis bundled in the image cannot be shared.
  • redis.enabled — Deploys the redis subchart and points ToolJet at it. When disabled, a single-replica ToolJet uses the Redis inside its own container.
  • redis.redis.auth.password.enabled / .value — Require AUTH on the Redis data node and wire the password into ToolJet. When enabled, the password is stored in a template-created secret that the ToolJet identity is granted reveal on.
  • redis.redis.resources / redis.sentinel.resources — CPU and memory bounds for the Redis and sentinel containers.
Keep redis.redis.replicas and redis.sentinel.replicas at 1. ToolJet’s Redis client is not Sentinel-aware and connects straight to the service DNS name, so additional data nodes would spread writes onto read-only replicas. The chart rejects any other value at render time.
Sessions stay valid across replicas, and long-lived websocket connections — the ones the multiplayer app editor uses — are not cut short by the workload request timeout.

Access

  • publicAccess.enabled — Serve the UI and API on the auto-assigned *.cpln.app HTTPS endpoint (default). Set to false for an internal-only instance: external requests are then refused at the edge, and in-GVC callers still reach it per internalAccess.
  • internalAccess.type — Controls which workloads can reach ToolJet over the internal network:
Firewall changes take a minute or two to propagate after a helm upgrade reports success.

Email

SMTP powers user invitations and password resets. It is off by default, and a default install works without it — the first visitor still becomes Super Admin.
For an authenticated relay, create the credentials secret before installing and reference it by name:
Leave smtp.auth.secretName empty for a relay that does not require authentication. When it is set, the ToolJet identity is granted reveal on exactly that secret.
Configure SMTP at the initial install. ToolJet seeds its mail settings from the environment during a first-boot migration, so enabling smtp.* through a later Helm upgrade has no effect — the values are applied to the workload but ToolJet keeps mail disabled. Decide before you install.

Connecting

Important Notes

  • Create the key secret before installingsecrets.name must point at an existing dictionary secret with SECRET_KEY_BASE, LOCKBOX_MASTER_KEY, and PGRST_JWT_SECRET. A missing secret pauses the deployment until the secret is created.
  • SECRET_KEY_BASE and LOCKBOX_MASTER_KEY are write-once — rotating LOCKBOX_MASTER_KEY makes every stored datasource credential undecryptable. Back the keys up outside Control Plane.
  • Do not lower tooljet.resources.maxMemory below 4Gi — the first boot’s migrations run out of memory below it and the workload never becomes ready.
  • Claim the Super Admin account right after install — the first visitor to complete onboarding owns the instance.
  • Configure SMTP at initial install — enabling it via a later upgrade silently does nothing.
  • tooljet.replicas of 2 or more requires redis.enabled: true, and both the Redis data node and sentinel must stay at one replica.
  • Change postgres.config.password before installing — it seeds the database on first boot and is not updated by later value edits.
  • All ToolJet state lives in PostgreSQL — apps, users, and ToolJet Database tables survive restarts and upgrades. Uninstalling deletes the database volume set and everything in it.
  • ToolJet is licensed under the AGPL — the deployed image is the LTS build and runs the free tier without a license key.

External References

ToolJet Documentation

Official ToolJet documentation

Environment Variables

Every setting the ToolJet server reads from its environment

ToolJet Database

The built-in PostgREST-backed database and its API

Super Admin

First-run onboarding and instance-wide administration

ToolJet on GitHub

Source code and release notes

ToolJet Template

View the source files, default values, and chart definition