Skip to main content

Cluster Tools Architecture

LaraKube CLI installs ready-made software — Cluster Tools — with one command per tool, like larakube notes:init. They run beside your own apps without cluttering their namespaces; Cluster Tools and Your Apps explains how the two share one cluster and one Commons.

Current suite includes:

  • Metabase (Insights): Business intelligence and beautiful data dashboards.
  • n8n (Flow): Open-source workflow automation.
  • Teable (Sheet): No-code spreadsheet database alternative.
  • Uptime Kuma: Status pages and uptime monitoring.
  • NetBird VPN: Zero-trust networking mesh.
  • GlitchTip: Sentry-compatible error tracking.
  • Gitea: Self-hosted Git forge and CI/CD pipelines.

The "Plex Commons" Design​

Rather than provisioning a separate, raw Postgres pod for every single tool, LaraKube integrates these tools with Plex Commons—our centralized, shared database and Redis engine.

Does sharing Postgres compromise security?​

No. LaraKube enforces strict, hard-shell isolation natively at the Postgres level. When a new tool is deployed, LaraKube executes idempotent tenant provisioning behind the scenes:

CREATE ROLE "metabase" LOGIN PASSWORD 'secure_pass';
CREATE DATABASE "metabase" OWNER "metabase";

Because Postgres 15+ secures the public schema by default, the metabase user has absolutely zero permissions to read or write to other tenant databases. Even if a hacker compromises a tool and gains direct access to its database credentials, they are physically walled off from lateral database traversal.

Secure Namespace Segregation​

Most Cluster Tools reside in the dedicated larakube-shared Kubernetes namespace; single sign-on, the VPN, secrets and passwords each get a namespace of their own.

This creates a deliberate blast-radius boundary:

  1. Isolated from Tenants: They are structurally separated from your actual project code and databases (each app's own {name}-{environment} namespace).
  2. Secret Constraints: By default, Kubernetes Pods cannot query the API for arbitrary secrets. If an attacker exploits a Remote Code Execution (RCE) vulnerability inside an n8n pod, they only have access to the flow-secrets explicitly mounted into that container. They cannot read Metabase's database password or any production app secrets.
  3. Opt-in VPN Whitelisting: Using the --vpn-only flag on installation instructs Traefik to inject NetBird zero-trust IP whitelisting middleware, meaning the tool's attack surface isn't even exposed to the public web.

A Note on Network Policies & Integrations​

Currently, pods within larakube-shared are free to communicate with each other over internal DNS (e.g., http://sheet-teable.larakube-shared.svc.cluster.local:8080).

This is an intentional design choice. It allows you to seamlessly construct workflows where n8n directly integrates with Teable or Metabase without routing traffic out to the public internet and back in.

If you were to implement strict Default-Deny NetworkPolicies in the future, these integrations would break unless you explicitly added Ingress network policy rules allowing the n8n pod to speak to the teable pod.

Disaster Recovery (DR)​

Because we shifted these tools to use Plex Commons, disaster recovery is vastly simplified:

  • Everything is Declarative: The deployments themselves are stateless. You can remove a tool with larakube <tool>:remove and regenerate the exact same architecture, ingress, and secrets by running larakube <tool>:init.
  • Centralized Database Snapshots: You don't have to manage five different SQLite files on five different persistent volumes. By backing up your single larakube-plex Postgres server (or taking automated snapshots of your DigitalOcean Managed Database), you are simultaneously backing up Metabase, n8n, Teable, and GlitchTip all at once.
  • Plex Native Backups: The CLI includes a native commonsBackupCommand() for generating zero-downtime SQL dumps.

(If you opt out of Plex via the --no-plex flag, tools will provision their own local SQLite databases mounted to physical PersistentVolumeClaims. DR in this scenario relies on your cluster-level volume snapshotting strategy, such as Velero).