- Your team owns your services and their uptime, and governs the cloud account they run in.
- LocalOps provisions the environment, configures it securely, and keeps deployments and the observability stack running.
- Your cloud provider runs the physical infrastructure and the managed services everything is built on.
What your team owns
Your applications
- Code and dependencies. Bugs, vulnerable libraries, and application-level authentication and authorization are yours to fix. LocalOps controls who can reach a service over the network, not what the service does once a request arrives.
- Container images. What runs inside your container is defined by your Dockerfile - base image, OS packages, the user it runs as, and which capabilities it needs. Keep base images patched, and run as a non-root user where you can.
- Uptime of your services. Crashes, memory leaks, slow queries and failing health checks in your app are yours to debug. LocalOps gives you the logs, metrics and alerts to do it.
- Health checks and resources. You define health checks and set CPU and memory for each service, so Kubernetes knows when to restart a container and how much room it has.
- Data inside your services. What you write to databases, caches, queues and buckets, its schema and migrations, and how long you keep it.
Your secrets and configuration
- Secret values. You decide what goes into secrets and when to rotate them, such as third-party API keys. LocalOps stores and delivers them securely.
- Sharing between services. A service only receives another service’s secrets when you import them. Keep imports to what each service needs.
ops.jsonchoices. Settings that loosen defaults are your call: making a database publicly accessible, privileged containers, or SSL passthrough (where your app then owns its own certificate).
Your cloud account
The environment lives in your account, so account-level governance stays with you:- Cloud account guardrails. AWS Organizations, service control policies, GuardDuty, Security Hub, AWS Config and budgets are yours to set up. Account-wide defaults, like EBS encryption by default, apply on top of what LocalOps configures.
- CloudTrail. Every action LocalOps takes in your account is recorded by CloudTrail. Keeping it enabled and retained is up to you.
- The connection role. You create the role LocalOps uses with CloudFormation, and you can revoke it at any time by deleting the stack.
- Quotas and cost. Service quotas, reserved capacity and the cloud bill for the resources in your environments.
Your network edge
- Domains and DNS. You own your domains, and point custom domains at your environment.
- Who can reach a web service. Per-service IP allowlists, and a WAF like Cloudflare in front of your services, are yours to configure. See Web application firewall with Cloudflare.
- Connecting other networks. VPC peering, Transit Gateway or VPN links to other networks, along with the routes and security group rules they need. Pick a custom CIDR when you create an environment if you plan to peer it.
Your people
- LocalOps account governance. Who you invite to LocalOps, what role they get, and removing people who leave.
- Cloud access. Who in your organisation has direct access to your AWS account outside LocalOps.
- GitHub / GitLab account. Who can push to the repositories and branches LocalOps deploys from, and which repositories you give LocalOps access to when you connect GitHub or GitLab.
- Privileged pod approval. Allowing privileged containers on a cloud connection is an admin decision you make.
What LocalOps owns
LocalOps provisions and configures everything between your code and the cloud provider, and keeps it working. See Environment security controls on AWS and GCP for the full list of what’s enabled.- Environment provisioning. A dedicated VPC and Kubernetes cluster for every environment, with subnets, NAT, load balancer, ingress, certificates, monitoring and backups set up from the start.
- Secure defaults. Private subnets, VPC-only security groups for data services, TLS on every web service, encryption at rest, a per-cluster KMS key, and control-plane audit logging.
- Least-privilege access. Keyless, short-lived access to your account, and per-component IAM roles. Your services’ role starts empty and only gains access to the dependencies you declare.
- Cloud resources you declare. Databases, caches, queues and buckets from
ops.json, created with encryption, backups and locked-down network access. - Automated deployment pipelines. Building your images on every push, rolling them out, and waiting for them to become healthy - one service at a time, without touching the others.
- Developer experience. The console, CLI, preview environments for pull requests, and built-in logs and metrics, so your team ships without writing infrastructure code.
- Secrets delivery. Storing secrets in your account and injecting them into the right containers, and only those.
- SSL certificates. Issuing and renewing SSL/TLS certificates for every web service and custom domain.
- Auto-scaling. Adding and removing replicas of your services on CPU, memory and schedules you set in
ops.json. - Observability stack. Running and keeping available the logs, metrics, dashboards and alerts in each environment.
- Backups set-up. Backup tooling in each environment, and automated backups for the databases and caches it creates.
What your cloud provider owns
- Physical infrastructure. Data centers, hardware, networking and the virtualization layer.
- Compute uptime. Availability of the virtual machines your nodes run on, and replacing failed underlying hosts.
- Managed services. Availability and durability of the managed services your environment uses, such as EKS, EC2, RDS, ElastiCache, S3, KMS and STS on AWS.
- Service-level guarantees. Uptime and durability as defined in each service’s SLA.