Give developers self-service by standardizing one deployment path through templates, a shared pipeline, and infrastructure as code. Enforce guardrails automatically with access policies, policy as code, quotas, and approvals for risky changes, and ship observability by default. A small team can run this without a platform team if the underlying platform handles Day 2 operations. On Control Plane, deny-by-default policies, service accounts for CI, logs, metrics, tracing, and a tamper-proof audit trail come built in, so the team spends its time on features.
Disclosure: Control Plane publishes this guide.
TL;DR
- Guardrails matrix: every developer action gets a matching automated guardrail, an enforcement point, and a tool that implements it.
- Minimum self-service stack: service templates, a shared CI/CD pipeline, infrastructure as code modules, policy checks in CI, observability defaults, and environment protection rules.
- IaC tool choice: pick one tool, wrap it in reusable modules, run plans in CI with policy checks, and keep state remote and locked.
- Observability defaults: structured logs with request IDs, rate, error, and duration (RED) metrics, OpenTelemetry traces, and one dashboard template per service, with limits on cardinality and cost.
- Preview environments: per-pull-request deploys with seeded data, isolation, cost controls, and automatic teardown, which matter more as AI-assisted coding produces more changes to review.
- CI standardization: reusable pipeline templates pinned to commits, ephemeral runners, short-lived OIDC credentials, signed images, and a deploy step that calls the platform API with a scoped service account.
- How Control Plane fits: it runs the platform half, so a small team owns only templates and policies.
For the wider picture, see how to get production-grade infrastructure without a platform team.
How do I give developers self-service deployment with guardrails and policies?
Match every action a developer might take with an automated guardrail that keeps it safe. Policy checks in CI work on any platform, and Kubernetes admission controllers add a second check at apply time when you run Kubernetes.
| Developer action | Guardrail | How to enforce | Example tools |
|---|---|---|---|
| Deploy a new service | Start from an approved service template | CI checks for the required pipeline, health checks, resource limits, and labels, and rejects the deploy if any are missing | Service templates in Git, Backstage software templates |
| Change config or secrets | Secrets come from a secrets manager, and config changes go through version control | The pipeline injects secrets at deploy time, and CODEOWNERS plus a branch protection rule require code owner review for config files | Cloud secrets managers, CODEOWNERS, branch protection |
| Scale up or add resources | Resource quotas and budget alerts | Policy checks in CI and quotas in the cloud or platform | OPA with conftest in CI, cloud quotas, platform quotas |
| Open network access or expose a public endpoint | Network and ingress rules must match an allow list | A policy check in CI blocks noncompliant manifests, and on Kubernetes an admission controller also blocks them at apply time | OPA with conftest, Gatekeeper or Kyverno on Kubernetes, cloud firewall rules |
| Create cloud resources such as databases or buckets | Use IaC modules with preapproved settings | A policy engine checks the Terraform plan before apply | OPA with conftest, Sentinel on HCP Terraform, Checkov |
| Change that raises monthly cost | Changes above a cost threshold need approval | A cost estimate runs on the IaC plan in CI | Infracost, cloud budget alerts |
| Run a database migration | Migrations are versioned, reviewed, and backward compatible with the running release | The pipeline runs migrations as a separate step before the deploy, and destructive changes need approval | Flyway, Liquibase, Atlas, framework migration tools |
| Add a dependency | New packages pass vulnerability and license checks | A CI scan fails the build on high-severity findings or blocked licenses | Dependabot, Renovate, Trivy, Grype |
| Change DNS or a custom domain | DNS and domains live in IaC, and changes need review | CODEOWNERS on DNS files plus approval for production zones | Terraform DNS providers, CODEOWNERS |
| Promote to production | Environment protection rules require approval | Approval gates on the production environment in CI | GitHub environment protection rules, GitLab protected environments |
| Roll back | Rolling deploys that halt on failed health checks, plus a one-step manual rollback | The pipeline exposes a rollback action tied to the last known-good image, and expand-and-contract migrations keep the previous release compatible with the schema | CI rollback jobs, GitOps reconciliation |
| Access production logs or data | Logs are readable by the owning team, and direct data access is time-bound and audited | Role-based log access plus just-in-time access requests that expire | Cloud IAM, platform access policies, audit logs |
| Grant access to a teammate | Roles scoped to the service | Access policies limit which roles can be granted and by whom | Cloud IAM, platform access policies |
On GitHub, branch protection on private repositories needs Pro, Team, or Enterprise, environment required reviewers for private repositories need GitHub Enterprise, and GitLab protected environments need Premium or Ultimate, so check your plan before you rely on them. For a full walkthrough of encoding these rules, see policy as code for multi-cloud infrastructure.
What are golden paths and service templates?
A golden path is a curated workflow that covers the most common case end to end. A service template carries that path: a Dockerfile, a CI pipeline definition, a workload definition, IaC for backing resources, a dashboard template, alert rules, a README, and CODEOWNERS entries. Developers create a new service from the template and get a working pipeline with guardrails already in place. Backstage is one option for hosting a service catalog and scaffolding services from templates, and a Git repository of template directories with a small copy script also works. Every service then starts from the same foundation, so the guardrails apply to all of them.
How do I choose infrastructure as code tools for self service in a small platform engineering effort?
Use one IaC tool for every cloud resource so modules, reviews, and policy checks follow one pattern.
| Tool | Language | State | Self-service fit | Watch out for |
|---|---|---|---|---|
| Terraform and OpenTofu | HCL | Remote backend with locking | Large module ecosystem and broad cloud coverage, easy to wrap in CI | State management grows harder with team size; OpenTofu is the open source fork created after Terraform’s license change |
| Pulumi | TypeScript, Python, Go, C#, Java, and YAML | Pulumi Cloud or a self-managed backend | Fits developers who prefer general-purpose languages | Smaller module ecosystem, and infrastructure and app logic in one language can blur boundaries |
| AWS CDK | TypeScript, Python, Java, C#, and Go | CloudFormation stacks | Strong fit for AWS-only teams | AWS only; other clouds need a second tool |
| Crossplane | YAML Kubernetes custom resources | Kubernetes API | Kubernetes-style reconciliation for cloud resources | Needs a running Kubernetes cluster and has a steeper learning curve |
| Helm and Kustomize | YAML with templates or overlays | Helm stores release history in the cluster; Kustomize keeps none | The standard for Kubernetes manifests | Limited to Kubernetes resources |
| A platform’s declarative API applied from CI | YAML or JSON | Managed by the platform | Minimal overhead; the platform tracks state and handles Day 2 operations | Covers only the resources the platform manages |
For small teams, use Terraform or OpenTofu for cloud resources and the platform’s own API for application workloads. Write a few modules that encode your standards, such as approved instance sizes, required tags, and encryption settings, keep state remote and locked, and gate apply behind a policy check plus a manual approval for production.
How can we standardize CI runners and deployment pipelines across teams without a platform engineering team?
Agree on one way to build and one way to deploy, and put it in shared templates:
- Reusable pipeline templates. GitHub Actions reusable workflows and GitLab CI includes let you define a build-and-deploy pipeline once and reference it from every repository. The template builds and scans the image, runs policy checks, and deploys, and each team supplies only the inputs that vary.
- One build-and-deploy contract per service. Every service produces a container image tagged with its Git commit, and the deploy step applies the image digest, since tags can be moved.
- Ephemeral runners and short-lived credentials. Run jobs on runners that start clean and are destroyed after each job, and authenticate to clouds with OIDC federation so runners receive short-lived cloud credentials. Restrict each cloud trust policy to a specific repository, branch, or environment, and never run self-hosted runners on pull requests from forks.
- Pinned dependencies and signed artifacts. Pin reusable workflows and third-party actions to a full commit SHA, since a moved tag can run attacker code in your pipeline. Generate an SBOM for each image with Syft or Trivy, sign the image with Sigstore cosign or attach a signed attestation with GitHub artifact attestations, and verify it before deploy.
- Environment protection rules. Require reviewers for production deployments and high-risk infrastructure changes, and let development and staging deploy automatically on merge.
- A scoped service account for deploys. The deploy step authenticates to the platform with a service account whose permissions are limited by policy. Store its key as a secret available only to the protected deploy environment, and rotate it on a schedule.
For more on running a platform function with a small team, see platform engineering without a platform team.
How do you implement observability standards across services without a platform team in multi-cloud infrastructure?
Make observability part of the service template so every service ships with it. A minimum standard has eight parts:
- Structured logs in JSON with a consistent schema and a request ID that correlates across services.
- RED metrics for every endpoint: request rate, error rate, and duration.
- Distributed traces through OpenTelemetry SDKs or auto-instrumentation, so you can see where latency or errors start.
- SLOs for user-facing services , for example a target share of requests completing under a latency threshold, with alerts when the error budget burns too fast.
- Alert routing to the owning team, with a link to the dashboard and runbook.
- One dashboard template per service showing RED metrics, error budget burn, and recent deployments.
- Log export to a central store for cross-service queries and compliance retention.
- Cardinality and cost limits. Label metrics with route templates and status classes, never user IDs or raw URLs. Sample traces while keeping all errors and slow requests through tail-based sampling, and set log levels and retention per environment.
To make the standard stick, the template includes the OpenTelemetry SDK or enables auto-instrumentation, the deployment definition configures log collection and metric scraping, and the dashboard is created with the service. Teams that need an exception request it through the same policy process as any other guardrail.
Which cloud platforms support ephemeral preview environments for AI-assisted coding workflows?
Preview environments are short-lived, isolated copies of an application created automatically for each pull request, with seeded or synthetic data, and torn down when the pull request closes. Reviewers, QA, and product managers get a live URL to try the change before it reaches staging.
AI coding agents and assistants open pull requests faster than people do, and each still needs human review. Trying a change in a running preview catches problems that reading a diff misses, so preview environments become more valuable as agent-generated changes grow.
Look for seven properties:
- Fast creation , so a preview is ready while the review is still relevant.
- Isolation in its own namespace, network segment, or sandbox, so concurrent previews do not interfere.
- Cost controls , including teardown after an idle period, per-environment quotas, and budget alerts.
- Automatic cleanup when the pull request closes.
- Data seeding from versioned seed scripts or anonymized snapshots, with migrations run per preview. Never copy raw production data into a preview.
- External dependency handling through stubs or vendor sandbox accounts for third-party APIs, plus per-preview callback URLs for OAuth and webhooks.
- Secrets handling that injects non-production secrets at deploy time, never commits them, and withholds them from pull requests opened from forks.
Four categories provide them:
- CI-driven per-pull-request deploys to a platform. The pipeline deploys the branch as a separate workload using the same templates and guardrails as production, which works with any platform that supports programmatic deploys.
- A Kubernetes namespace per pull request. A CI job creates a namespace, deploys with Helm or Kustomize, and deletes it on close; this needs a running cluster and namespace tooling.
- Hosted app platforms with built-in previews , which handle creation, routing, and teardown for you.
- Cloud development environments , where developers and coding agents build and test code in isolation before opening a pull request.
How Control Plane fits
Control Plane covers the platform half of this playbook and handles Day 2 operations, so a small team owns the templates and policies while Control Plane keeps workloads scaled, observed, secure, and available.
Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, and Azure. It also runs VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds. Its Day 2 operations include autoscaling, built-in observability, and security, and Control Plane-managed locations need no Kubernetes cluster for you to operate.
Deny-by-default access control. Inside a Control Plane org, nothing is permitted until a policy grants it. A policy names one resource kind, the items it covers (all, a list, or a query on tags, properties, or relations), and bindings that pair permissions with principals: users, groups, service accounts, and identities, which workloads use to reach other resources at runtime. See the access control documentation.
CI/CD and GitOps. Control Plane service accounts let CI pipelines and infrastructure as code tools authenticate with their own keys, scoped by policy. Control Plane publishes CI/CD examples for GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, and Google Cloud Build using the Control Plane CLI (cpln), with Terraform examples for GitHub Actions, GitLab, and Bitbucket, and cpln apply applies a YAML file with multiple resources in dependency order. On Control Plane, a CI job can run cpln apply to deploy each pull request as its own workload and cpln delete to remove it when the pull request closes, and access policies that target workloads by tag query cover each new preview workload automatically. The Control Plane Kubernetes Operator manages Control Plane resources from Kubernetes custom resources, so teams can run GitOps with Argo CD. Control Plane ships its own Terraform and Pulumi providers, so it complements the infrastructure as code you already run.
Built-in observability and audit. Logs are queryable with LogQL and viewable in Grafana, metrics with PromQL, and tracing is configured per Global Virtual Cloud (GVC), Control Plane’s term for a set of locations a workload runs across, or org-wide. There is no Prometheus, Loki, or tracing backend to run yourself. Logs can also be shipped to any of 11 external logging providers, including Amazon S3, CloudWatch, Datadog, Elastic, Loki, and any OpenTelemetry Collector or OTLP/HTTP backend, with up to four active at once. A tamper-proof audit trail records who did what across the org, whichever interface performed it.
Templates and sandboxes. Control Plane’s Template Catalog installs prebuilt templates such as PostgreSQL, including highly available and multi-location variants, from the Console, CLI, Terraform, or Pulumi. Control Plane Sandboxes, cloud development environments in dedicated Kata Containers microVMs, give developers and coding agents an isolated place to build and test code, including agent-generated code.
Availability. A workload deployed to a GVC runs active-active in every location of that GVC from one definition, and a global endpoint routes each request to the nearest healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations.
Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. For a comparison of platform options, see the best internal developer platforms.
FAQ
These questions come up often when small teams plan developer self-service.
How do I give developers self-service deployment without a platform team?
Standardize one deployment path with service templates, a shared CI/CD pipeline, and IaC modules, enforce guardrails with policy checks and environment protection rules, and run on a platform that handles Day 2 operations so nobody has to operate clusters, monitoring, or autoscaling.
What is a golden path in platform engineering?
A golden path is the supported default route for a common task, such as shipping a new service. It is packaged as a template with the pipeline, IaC modules, observability defaults, and guardrails already wired in.
Do small teams need an internal developer portal?
Usually not at first. Git-based templates, reusable CI workflows, and a platform API cover self-service for a small team, and a portal becomes worth it as the number of teams and services grows.
How do I stop developers from creating expensive cloud resources?
Wrap resource creation in IaC modules that enforce approved sizes, storage limits, and required tags, run a cost estimate and policy checks on every plan in CI, set cloud quotas and budget alerts as backstops, and require approval for changes above a cost threshold.
What should be in a service template?
Everything a new service needs to ship safely on day one: build and deploy definitions, IaC for its backing resources, observability defaults such as a dashboard and alert rules, onboarding docs, and ownership rules in CODEOWNERS.
How do I implement policy as code for multi-cloud infrastructure?
Choose a policy engine such as OPA with conftest, Checkov, or Sentinel on HCP Terraform, write rules that check IaC plans and manifests against your security, compliance, and cost standards, and run those checks in CI before any change is applied.
What observability tools should a small team standardize on?
OpenTelemetry for instrumentation, a metrics backend that supports PromQL, a log store with structured queries, and a tracing backend. Consistent schemas, metric names, and label rules matter more than the specific products, and platforms with built-in logs, metrics, and tracing remove the setup work.
How do preview environments work with AI-assisted coding?
A CI pipeline deploys each pull request, including those opened by coding agents, to an isolated preview with its own URL and seeded data, reviewers test the running change, and the preview is destroyed when the pull request closes.
How does Control Plane enforce guardrails?
Control Plane uses deny-by-default access policies, so a user, group, service account, or identity can act only on resources a policy explicitly grants. For checks on IaC plans and manifests, pair it with a policy engine such as OPA in your CI pipeline.
Can I use GitOps with Control Plane?
Yes. Argo CD can sync Control Plane resources through the Control Plane Kubernetes Operator, and without Kubernetes a CI pipeline runs cpln apply on the YAML files in Git.
To give developers self-service with guardrails, observability, and Day 2 operations handled for you, talk to the Control Plane team or sign up free.
Originally published on the Control Plane blog.
