Why one environment per developer
- No waiting. Developers test their work as soon as it’s pushed, instead of waiting for a shared staging slot.
- No stepping on each other. Each environment has its own network, cluster, databases and secrets. A bad migration or a load test in one environment can’t break anyone else’s.
- Production-like. It’s the same kind of environment your production runs on - same cloud, same
ops.json, same security controls - so “works in my environment” means something. - Easy hand-off. Product managers, designers and QA get a stable URL to review a feature before it’s merged.
What every environment comes with
Each developer environment is set up with the same building blocks as production, automatically. Nobody has to install or wire anything up. Infrastructure- A dedicated VPC with private and public subnets, and its own Kubernetes cluster
- A load balancer and ingress, with a public HTTPS URL for every web service
- SSL certificates, issued and renewed automatically
- A static outbound IP, so third-party APIs can allowlist the environment
- Auto-scaling for services that need it
- Logs. Every container’s logs are collected into Loki, searchable in Grafana, and kept for 30 days. No log drains to configure - just print to stdout. See Logs.
- Metrics. Prometheus collects CPU, memory, disk and network metrics for every node, pod and service, with pre-built Grafana dashboards. See Metrics.
- Grafana. Each environment gets its own Grafana, on its own HTTPS URL behind a login, opened from the environment’s Monitoring tab. Build your own dashboards and alerts in it.
- CLI access. Stream logs, open a shell or a database console, and forward ports with the
LocalOps CLI, without
kubectlor cloud credentials.
- Services, databases and caches in private subnets, with no public IPs
- Encryption in transit and at rest
- Keyless, least-privilege cloud access for your services - no access keys to manage
- Secrets stored in your cloud account and injected only into the services that need them
- Databases, caches, queues and buckets you declare in
ops.json, created fresh for each environment - Backup tooling for the environment’s volumes, and automated backups for the databases it creates
Set it up once
An admin does this once. After that, developers serve themselves.- Connect a cloud account. Connect an AWS or GCP account for developer environments. Keeping them in a separate account from production keeps their cost and blast radius separate too.
- Create a project for developer environments. Put them in their own project, so developers’ access is scoped to it.
- Invite developers as Members. Invite each developer to the project with the Member role. Members can create and manage environments and services inside their project, but can’t change project settings or see other projects - including production.
- Describe your stack in
ops.json. Declare the databases, caches, queues, buckets, init jobs and health checks your services need inops.jsonin each repo. Every new environment then gets its own copies automatically, with no manual wiring.
What developers do themselves
Spin up their environment
From the LocalOps console, a developer creates an environment - saydev-alice - in the cloud
account connected for developer environments, in a region close to them. LocalOps provisions a dedicated network and
Kubernetes cluster for it.
Add services from their branch
They create a service for each part of the app - web, API, workers, cron jobs - pointing at the repo and the branch they’re working on. LocalOps builds each one and creates the cloud resources declared in itsops.json, like a fresh database just for this environment.
Deploy by pushing code
Every push to that branch deploys automatically. There’s no pipeline to write and no one to ask. Developers can also redeploy or roll back from the console.Manage config and secrets
Developers set environment variables and secrets for their own environment, like a test API key for a payment provider, without affecting anyone else’s.Debug on their own
With the LocalOps CLI, developers can work with their environment from the terminal:Share it
Web services get a public HTTPS URL out of the box, so a developer can send a link to QA or a product manager for review. To keep a developer environment private, restrict it to your office or VPN IPs with the web service’s IP allowlist.Tear it down
When the feature ships, the developer deletes the environment, and its cloud resources go with it. Spinning up a fresh one later takes the same few steps.Creating a new environment takes about 20 minutes, since it provisions a dedicated network and cluster. Most teams
keep each developer’s environment running and just point its services at new branches, instead of creating one per
feature.
Keep costs in check
- Right-size services. Give developer environment services less CPU and memory, and fewer replicas, than production.
- Use spot capacity. Run developer environment node groups on spot instances.
- Tear down idle environments. Delete environments nobody is using, and recreate them when needed.
- Track cost per environment. Use resource tags to find each environment’s resources and their cost in your cloud bill.
Overall steps
- Admin connects a cloud account and a project for developer environments, and invites developers as Members
- Teams declare their dependencies in
ops.json - Each developer creates their own environment
- They add services from their branch and push to deploy
- They debug with the CLI and dashboards, and share the URL for review
- They delete the environment when they no longer need it
Get started now
Sign up for free
Create your account and connect your cloud to get started.
Book a demo call
We’ll walk you through the setup personally.
Email support
Questions? Write to us at support@localops.co.