Documentation Index
Fetch the complete documentation index at: https://docs.localops.co/llms.txt
Use this file to discover all available pages before exploring further.
May 22, 2026
Deletion protection for critical services
You can now turn on deletion protection for a service from its settings. Once enabled, the service cannot be deleted until protection is explicitly turned off — a safety net for production and other critical services where an accidental delete could cause downtime.May 21, 2026
✋ Improvements and bug fixes
We have shipped a handful of bug fixes and small enhancements today to make day-to-day operations smoother. These are the kind of polish that adds up over time. Read on for the highlights.Stop and start services on demand
Each service dashboard now has a Stop button in the top right corner. Use it to scale down a service’s replica/container count to0 on demand, without deleting the service or its configuration. Click start button to bring it back up.Consistent image tag on redeploys
After updating secrets or scaling settings, users can trigger a new deployment. For docker image based services, this deployment was previously pulling the image with thelatest tag. It now uses the exact image tag from the previous deployment, so redeploys stay consistent with what was last running.May 19, 2026
Valkey support for ElastiCache
ElastiCache clusters declared inops.json can now use valkey as the engine, alongside redis and memcache. Pick a supported version from the AWS Valkey versions list. See ElastiCache for details.May 14, 2026
SSL passthrough
Services can now handle TLS termination themselves instead of letting the environment’s nginx ingress decrypt traffic. Setssl_passthrough to true in ops.json and configure your service’s port to 443 so the ingress forwards raw TLS connections directly to your container. Useful for mTLS, custom certificate handling, or any protocol requiring end-to-end TLS. See SSL passthrough for details.May 13, 2026
Instrument services with internal /metrics endpoint
You can record custom metrics and expose them to in-built prometheus monitoring stack via/metrics endpoint. Just add an ops.json file in your repository and declare “metrics” configuration as documented here - Instrument services to get started.- language run time metrics - NodeJS event loop metrics, JVM metrics, etc.,
- connection and request metrics like “tcp_connections_open”
- business metrics like “number_of_payments”
- transactional metrics like “number_of_emails_sent”
Pro tip - Checkout the language specific guides to learn how you can unveil advanced metrics & dashaboards in just few mins of setup (eg: See this Java guide)
Request timeouts
Set timeouts for TCP connections or requests handled by your services. Default timeout 60s may not be suitable for realtime applications with long running connections. Start declaring custom timeout values in ops.json as specificed in developer docs - Request timeouts.Private IPs passed as environment vars
POD_IP and HOST_IP are now injected in each service as environment variables. So if your application requires its own IP address, you can fetch and utilize in your business logic.Learn more about built-in environment vars like these.Other UI enhancements and fixes
- Saving secrets triggers a “Write secrets” op to keep track of secret updates
- While creating new service, search for repositories using the new search bar in the repository picker
- Bug fixes in Member invite workflow
- Bug fixes in preview environments
- Other fixes in slack and ms teams notificaitons
April 18, 2026
Projects revampled
We have revamped Projects. You can now create projects and organize environments in them.Members
Projects can have members. Unless an org member is also added as a project member, they can’t see the project’s environments or deploy to them.Revampled navigation bar
Sidebar navigation menu is revamped to make it easy to switcher between organization and projects.Other bug fixes and UI enhancements were made too.April 9, 2026
Organization SSO (SAML 2.0)
We’ve introduced Single Sign-On (SSO) via SAML 2.0, allowing teams to manage access through their preferred identity providers. This feature simplifies user onboarding and enhances security by centralizing authentication.
- Okta
- Microsoft Entra ID
- Google Workspace SSO
- OneLogin
- Auth0
What’s Next: OIDC (OpenID Connect) support is currently in development and will be released soon.
Improved CLI Organization Management
Users who belong to multiple organizations can now explicitly select their active organization directly within the Command Line Interface (CLI). This ensures that commands and deployments are always targeted at the correct environment without manual configuration overrides.Simplified Manual Deployments
To streamline the redeployment process, we’ve added a new option in the manual deployment section. You can now quickly select and use the last successfully deployed Docker or Helm images, reducing the risk of version mismatch during quick fixes or rollbacks.Security Improvements
We’ve strengthened the security of our OAuth device authorization flow to further using stricter state validation and session integrity.March 31, 2026
Switch organizations/teams & New CLI update
If you run multiple products and multiple engineering teams handling their own qa, uat and production environments, you will love this update.Switch organizations:Users can now belong to multiple organizations using their same login / email address. And they can easily switch between the organizations from the top left menu like this:
- Github org
- ECR Registries
- Environments
- qa
- uat
- production
- Deployments


March 6, 2026
Custom CIDRs for environments
While creating new environments, you can now specify custom CIDR block for your environments. This will be used to create VPCs and subnets in your cloud accounts and will give more control over your network configurations.In the Create environment page, you can click on “Advanced options” to see the new field for custom CIDR block. You can specify any valid CIDR block that you want for your environment.
March 3, 2026
Realtime run status of services
We released a major new enhancement to services today. You can now see the realtime status of all services running within each environment, without having to use LocalOps CLI or Kubectl CLI.
web, internal services and worker services, you will see the following statuses:- running (2/2)
- degraded (1/2)
- failing (0/2)
- stopped
- pending
- succeeded
- failed
- timeout
- idle
- active
- suspended
New “Runs” tab
Lookout for the new “Runs” tab for job and cronjob services. You can see the run history and status of each run.We update statuses in near real time so you would know when you service is failing, just by looking at the status text in LocalOps console.All of these changes were made to make it easier for you to monitor and manage your services, without having to drop into shell or CLI.Feb 27, 2026
New feature: Custom Node groups
So far, environments have been having a single node group created, to run all the services.Now, you can create multiple node groups to run different types of services. For each node group you can pick- AMIs
- Instance types
- Desired count of nodes

- Windows node groups to run windows based services (or)
- Linux node groups to run linux base services
Spot instances
In the case of AWS evnironments, while creating node groups, you can pick between ON_DEMAND or SPOT as capacity types.So you can create node groups of SPOT instance type and assign interruptible and idempotent services like jobs, crons, batch processing, or other. This will end up giving up to 50% savings in compute costs.Feb 9, 2026
New feature: Deployment notes
While triggering new deployments, you can now pass a note text to it. And it will communicate to rest of the team about what the deployment is all about.We made other QoS updates here to ensure smooth execution of deployment pipelines.Feb 7, 2026
New feature: Account level resource tags
All cloud resources of all environments spinned by LocalOps are attached with two standard tags. One with ID of the environment and another with name of the environment. These tags can be used in Cost explorer to analyse costs at a granular level.We released a new feature today to accept custom tags so that you can assign your own key value pairs as tags for all resources spinned up in all environments of the account. You can use it to attach tags like:bu: internalbu: product-1project: project-name
Jan 13, 2026
Bring your own registry
LocalOps can now use your images from your own docker registry to deploy services in your environments. Go to the new Registries section to add any private docker registry.We support ECR & DockerHub as of today and plan to support other providers in the coming weeks.- Amazon Elastic Container Registry (ECR)
- DockerHub
- Google container registry
- Azure container registry
- Github packages
Bring your code pipeline
Deploy using LocalOps API
You can run your exisitng code build pipelines to build code and finally call LocalOps API to deploy the code to your environment. Checkout the API reference for the new /deploy api here.Eg.,🍦 Deploy using LocalOps Github action
To cut work, you can also embed our Github action step directly within your.github/workflows/deploy.yml to trigger
new deployments.Like:docker_image_tag or commit_id or helm_chart_version to the action to trigger new deployments.or with commit sha like: