Choosing Between Gitpod SaaS and Self‑Hosted: Cost, Compliance, and Custom Images

Problem and takeaway

You need a reproducible, container‑based development environment but must decide whether to use Gitpod’s hosted SaaS offering or run your own self‑hosted instance. The decision hinges on budget, data‑residency compliance, the need for custom Docker images, and how long workspace state should persist between sessions. The takeaway: if you prioritize zero‑ops setup and can tolerate per‑hour charges, SaaS is the simplest path; if you require full control over images, storage, or network policies, self‑hosted on Kubernetes gives you that control at the cost of operational overhead.

Decision constraints

Budget

SaaS bills per active workspace hour (plus any storage overrun). Self‑hosted shifts the cost to your cluster infrastructure (nodes, storage, networking) and you pay only for the underlying resources.

Compliance / data residency

SaaS stores workspace containers and logs in Gitpod’s cloud regions, which may not satisfy strict data‑location rules. Self‑hosted lets you keep all data inside your own VPC or on‑premises network.

Custom images

Both models allow a custom Dockerfile, but SaaS restricts you to the base images provided by Gitpod’s builder; you cannot install privileged packages or modify the host OS. Self‑hosted lets you use any image, run privileged containers, and expose additional host‑side volumes.

Workspace persistence

SaaS offers optional persistent storage via a mounted PVC, but size limits are tied to your plan. Self‑hosted lets you define the size and class of the persistent volume, and you can attach external storage systems (e.g., NFS, CSI drivers).

Comparison of supported options

Aspect	Gitpod SaaS	Gitpod Self‑Hosted
Infrastructure management	None (fully managed)	You provision and maintain a Kubernetes cluster (or VMs)
Cost model	Per‑hour workspace usage + storage	Cluster compute/storage costs only
Data residency	Gitpod‑selected regions	Full control (your VPC/on‑prem)
Custom Dockerfile privileges	Limited to user‑namespace builds; no privileged mode	Full privileged builds, custom base images
Persistence size	Plan‑dependent quota (e.g., 10 GB free)	Defined by your PVC/storage class (practically unlimited)
Operational overhead	Minimal (just .gitpod.yml)	Cluster upgrades, TLS, RBAC, monitoring

Trade‑offs explained

If your team’s monthly budget for development environments is under a few hundred dollars and you can accept the provider’s regional restrictions, SaaS eliminates the need to manage Kubernetes, Helm charts, or certificate rotation. The trade‑off is that you cannot run containers that require CAP_SYS_ADMIN or load custom kernel modules, and you are subject to the provider’s hourly pricing changes.

Conversely, self‑hosted gives you the ability to:

• Use any base image (including those with proprietary libraries).
• Enforce network policies that keep workspace traffic inside a private subnet.
• Scale the cluster based on actual usage, potentially lowering cost per workspace hour for large teams.
• Attach high‑performance storage (e.g., SSD‑backed PVCs) for large monorepos.

The downside is the operational burden: you must keep the cluster patched, configure ingress TLS, set up RBAC for Gitpod’s controller, and monitor resource quotas. If you lack a platform team, this overhead can outweigh the benefits.

Concrete implementation / validation

Below is a minimal, end‑to‑end example that works for either option. It shows how to define a custom workspace image and verify that the environment starts correctly.

1. Create a custom Dockerfile

Save this as Dockerfile in the root of your repository:

FROM gitpod/workspace-full:latest

# Install a specific version of Node.js as an example
RUN sudo apt-get update && \
    sudo apt-get install -y curl && \
    curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - && \
    sudo apt-get install -y nodejs

# Verify installation
RUN node --version

This file extends the official Gitpod full workspace and adds Node.js 20. It does not require privileged mode, so it builds in both SaaS and self‑hosted.

2. Add a .gitpod.yml configuration

Place this alongside the Dockerfile:

# .gitpod.yml
image:
  file: Dockerfile

# Start a VS Code server with the custom image ready
tasks:
  - init: npm install
    command: npm run dev

# Optional: persist the node_modules directory across restarts
ports:
  - port: 3000
    onOpen: open-preview

3. Validate the workspace (SaaS)

1. Push the repository to a Git host (GitHub, GitLab, or Bitbucket).
2. In the Gitpod dashboard, click “New Workspace” and select the repo.
3. When the workspace starts, open a terminal and run node --version. You should see v20.x.x.
4. Run npm install (the init task) and confirm it completes without error.
5. Stop the workspace, then start it again; verify that node_modules is still present (persistence depends on your plan’s storage quota).

4. Validate the workspace (self‑hosted)

Assuming you have a running Kubernetes cluster with the Gitpod Helm chart installed:

1. Ensure your values.yaml includes a storage class for workspaces, e.g.:

workspace:
  persistence:
    enabled: true
    size: 20Gi
    storageClass: standard

1. Apply the chart: helm upgrade --install gitpod gitpod/gitpod -f values.yaml
2. Push the same repo to your Git host.
3. In the self‑hosted Gitpod UI, launch a workspace from the repo.
4. Inside the workspace, run node --version and confirm the version.
5. Check the persistent volume claim: kubectl get pvc -n gitpod should show a bound claim with the size you set.
6. Restart the workspace and verify that node_modules remains.

5. Practical checks and limitations

To confirm that your choice meets the original constraints:

• Cost: For SaaS, view the “Usage” page in the Gitpod console after a few days of use; multiply the reported hours by the current per‑hour rate. For self‑hosted, check your cloud provider’s billing for node hours and storage.
• Compliance: Inspect the region of the created pods (SaaS) or the nodes (self‑hosted) to ensure they lie within allowed jurisdictions.
• Custom image: If you later need a privileged container (e.g., to run Docker-in-Docker), test it only on the self‑hosted instance; the SaaS build will fail with a permission error.
• Persistence: Write a test file to /workspace/test.txt, stop the workspace, start it again, and verify the file exists. If it disappears, your storage class or quota is insufficient.

Remember that pricing tiers and free‑tier limits can change; always consult the latest Gitpod pricing page before committing to a budget. Similarly, keep your cluster’s Kubernetes version compatible with the Gitpod Helm chart (check the chart’s README for supported versions).