This is a design note, not a finished implementation. The goal is to build a small Kubernetes developer platform on an existing k3s cluster so developers can run databases, caches, APIs and temporary web workloads without turning every laptop into a miniature production environment.
The constraint matters: there is already a working k3s cluster and room for additional worker nodes, but not enough hardware for a second three-control-plane cluster dedicated only to Rancher. That makes this a useful exercise in practical platform engineering—start with the smallest credible pilot, document the compromises, and create a path to a more resilient design later.
Table of contents
The problem the Kubernetes developer platform should solve
The immediate problem is not “we need a portal.” It is that local Docker Desktop environments consume CPU, memory and battery, while every developer maintains a slightly different copy of the same supporting services. A laptop may be running PostgreSQL, Redis, RabbitMQ, an API and a frontend before any real development begins.
A shared Kubernetes developer platform can move that load to existing infrastructure. Developers should be able to request a temporary PostgreSQL or Redis instance, deploy an API image, receive an internal URL and remove everything when the work is finished. The experience needs to be simple, but the controls underneath it must remain explicit.
For this environment, “platform” does not initially mean a large custom product. It means a carefully limited combination of k3s, Rancher Projects, namespaces, RBAC, resource policies, Helm charts and GitLab CI.
1. Start with a thin self-service layer
The first design decision is to use Rancher and a small internal Helm catalog before considering Backstage or a custom portal. Backstage can be valuable when an organization needs a broad software catalog, templates, ownership metadata and integrations across many systems. It also introduces another application, another plugin ecosystem and another operating model.
The first version only needs a few repeatable actions:
- Create or select an assigned developer namespace.
- Deploy PostgreSQL, MySQL, Redis, MongoDB or RabbitMQ with approved defaults.
- Deploy a generic API or web container from an approved image registry.
- Set a small number of parameters such as image tag, storage size and expiration time.
- See status, logs and the internal endpoint without receiving broad cluster privileges.
Rancher can expose a private Helm repository through its Apps interface. A chart can include a questions.yml or questions.yaml file so common values appear as a form rather than as raw YAML. That is enough to test whether self-service actually reduces developer friction. The official Rancher documentation covers both repositories and apps and chart questions.
2. Treat same-cluster Rancher as a pilot compromise
For a resource-constrained pilot, Rancher can run as a single replica on the existing k3s cluster. That is technically possible, but it must not be described as the production reference architecture. Rancher’s own architecture recommendation is a separate, highly available management cluster for production.
Running the management plane and developer workloads together creates correlated failure modes. If that cluster is unavailable, both the workloads and the interface used to manage them are affected. If only Rancher is unavailable, downstream Kubernetes workloads normally keep running, but Rancher-based access and workflows may be temporarily unavailable. An independent administrator kubeconfig and tested backups therefore remain essential.
The pilot should state its boundary clearly:
| Choice | Pilot position | Future trigger |
|---|---|---|
| Rancher placement | Existing k3s cluster | Move to a dedicated management cluster when the service becomes operationally important |
| Rancher replicas | One | Use HA when hardware and availability requirements justify it |
| Authentication | Small trusted test group | Add Entra ID or another central identity provider before broader adoption |
| Availability | Best effort | Define an SLO once teams depend on it |
This distinction prevents a temporary constraint from quietly becoming permanent architecture.
3. Isolate developers with projects, namespaces and RBAC
Each developer—or small team—should have a Rancher Project containing one or more namespaces. Projects provide a useful administrative boundary for namespace membership, roles and aggregate quotas. The Rancher Projects documentation explains how these controls apply across namespaces in a project.
A simple initial convention might be:
dev-sandbox-alex
dev-sandbox-mira
dev-shared-services
Developers should receive Project Member or appropriately scoped namespace permissions—not local-cluster Owner or Administrator. Rancher treats the local cluster as especially sensitive, and its authentication guidance recommends limiting access to trusted administrators.
Namespace isolation is not a complete security boundary by itself. Before moving beyond a friendly internal pilot, add NetworkPolicies, Pod Security Admission settings, controlled image registries, secret-management rules and audit logging. The initial Kubernetes developer platform should be honest about what it protects and what it does not.
4. Reserve worker capacity for developer workloads
Adding dedicated developer workers is more valuable than immediately building a second management cluster. Label and taint those nodes so sandbox workloads land there and production workloads do not consume the same capacity by accident.
kubectl label node dev-worker-01 workload=developer
kubectl taint node dev-worker-01 workload=developer:NoSchedule
Each approved chart can include the matching scheduling rules:
nodeSelector:
workload: developer
tolerations:
- key: workload
operator: Equal
value: developer
effect: NoSchedule
A taint repels pods without a matching toleration, while the node selector positively chooses the developer pool. Kubernetes documents the behavior in Taints and Tolerations. This is capacity isolation, not a security control, but it gives the pilot a predictable place to grow.
5. Put quotas and defaults in place before onboarding
Self-service without guardrails eventually becomes shared-cluster contention. Apply a Project Resource Quota and namespace defaults before the first broader test. Rancher supports project-level quotas, while native Kubernetes ResourceQuota and LimitRange objects provide the underlying controls.
An illustrative starting budget for one developer sandbox could be:
| Resource | Initial limit | Reason |
|---|---|---|
| CPU requests | 2 cores | Encourages realistic requests |
| CPU limits | 6 cores | Allows short bursts without taking the pool |
| Memory requests | 4 GiB | Supports a small application stack |
| Memory limits | 12 GiB | Caps runaway workloads |
| Persistent storage | 30 GiB | Enough for temporary development data |
| Pods | 20 | Prevents accidental deployment storms |
| PVCs | 8 | Limits abandoned volumes |
These are starting values, not universal recommendations. Observe real usage for one or two weeks and adjust them. Charts should also define sensible resource requests and limits so a developer cannot unknowingly deploy an unbounded service.
6. Build images in GitLab CI, not on laptops
Moving databases to the cluster but continuing to build every application image locally only solves half the problem. The cleaner workflow is:
- A developer pushes a branch to GitLab.
- GitLab CI builds and scans the container image.
- The pipeline pushes a tag such as the branch slug or commit SHA to the registry.
- The developer selects that tag in the Rancher catalog form.
- The chart deploys the API or frontend into the assigned namespace.
This makes the registry the handoff point and removes local Docker builds from the critical path. It also creates a consistent record of which source revision produced an image.
Database and cache charts can be immediately useful, but access from a laptop to a service such as postgres.dev-sandbox.svc.cluster.local still needs a deliberate path. During the pilot, kubectl port-forward may be acceptable. Later options include VPN access, an internal proxy or carefully controlled ingress. Do not expose stateful development services publicly merely to make the first demo convenient.
7. Make expiration part of every deployment
A shared sandbox without expiration becomes a cemetery of forgotten databases, PVCs and branch environments. Every deployable unit should carry ownership and lifetime metadata from day one:
metadata:
labels:
platform.infrafieldnotes.com/owner: alex
platform.infrafieldnotes.com/ttl: 1d
The catalog can offer a small fixed list—four hours, one day, three days or seven days. A scheduled cleanup job can remove expired releases and optionally retain their PVCs for a short recovery window. The exact controller can evolve, but the lifecycle contract belongs in the first version of the Kubernetes developer platform.
Feature environments are a natural second phase: a branch image, optional database and Redis release, plus an internal URL such as feature-123.dev.example.internal. TTL cleanup is what keeps that convenience economically and operationally sustainable.
A realistic first milestone
The smallest useful milestone is deliberately modest:
- Install one Rancher replica on the existing k3s cluster and record that this is a pilot exception.
- Create one project and one namespace such as
dev-sandbox-alex. - Apply RBAC, a quota and default resource limits.
- Publish three catalog items: PostgreSQL, Redis and a generic container.
- Let one developer use the environment for one to two weeks.
- Measure setup time, resource use, abandoned workloads and the tasks that still require an administrator.
Only after that test should the platform add GitLab CI templates, wildcard internal ingress, automated TTL cleanup, dedicated developer workers and centralized authentication. The order is important: validate the workflow before investing in a polished portal.
Conclusion
A useful Kubernetes developer platform does not begin with a large portal. It begins with a narrow contract: approved services, isolated namespaces, bounded resources, repeatable image delivery and automatic cleanup. Rancher on the existing k3s cluster can test that contract, provided everyone understands the availability compromise and administrators keep independent access.
If the pilot proves that developers spend less time maintaining local infrastructure, the next investments become obvious. Add dedicated capacity, stronger policy, centralized identity and eventually a resilient management plane. That is a safer path than building a complex platform before knowing which parts developers will actually use.