SquareOps
Get an architecture review

How SquareOps Helped Nimbbl's 40 Engineers Self-Manage Kubernetes Environments on AWS EKS

SquareOps Team October 28, 2026 Case Studies

The Challenge

As the engineering team grew, so did the work of managing Kubernetes environments.

  • A non-prod bottleneck. Developers needed staging, QA and dev environments, but creating and managing them went through a small infrastructure team.
  • Inconsistent deployments. Without a standard process, teams deployed differently across environments, which caused configuration drift and bugs that were hard to reproduce.
  • Environment variable sprawl. Managing configuration and secrets across services and environments was manual and error-prone.
  • Environments running around the clock. Non-production environments ran 24/7 although developers only needed them during working hours.

What SquareOps Did

Nimbbl needed to give 40 engineers self-service access to Kubernetes without losing control of production. SquareOps worked with its platform team and ran the environments through Atmosly, where developers act within guardrails the platform team sets.

  • Self-service non-prod environments. Every developer can create, manage and tear down non-production environments without a ticket. Role-based access means developers reach only the environments they own, and production stays isolated.
  • Scheduled start and stop. Environment scheduling stops non-production environments outside working hours and starts them again when developers need them.
  • One pipeline for every environment. Atmosly pipelines became the single way to build and deploy, from dev to production. Every team follows the same templates for build, test, scan and deploy, and developers run pipelines themselves with visibility into build logs, deployment status and rollback options.
  • Central environment variables. Variables are scoped per environment and service, with audit trails and access controls, and developers can update the variables of their own environments without access to the cluster.

Results

  • 40 engineers self-managing environments. Developers create and manage non-prod environments themselves, with no DevOps gatekeeping.
  • Daily deployments across teams on standard pipelines, so every team ships the same way.
  • Non-production environments no longer run around the clock. They run when developers need them.
  • Secure self-service. Role-based access and central variable management gave developers freedom without exposing production.
  • A freed-up platform team. It moved from handling environment requests to reliability and scale.

Conclusion

For a payments platform where uptime is not negotiable, the infrastructure workflow had to be as dependable as the checkout flow. Self-service environments, standard pipelines and central configuration let 40 engineers move fast, while the platform team stays focused on keeping production solid.

Frequently Asked Questions

How many engineers manage their own environments at Nimbbl?

All 40 engineers can create, manage and tear down non-production environments themselves, without raising a ticket.

How does Nimbbl keep production safe with self-service?

Role-based access limits developers to the environments they own, and production stays isolated and under the platform team.

How are deployments standardized?

Every team uses the same pipeline templates for build, test, scan and deploy across all environments, and developers run the pipelines themselves.

How are environment variables managed?

They are scoped per environment and service, with audit trails and access controls, and developers can update their own environments without cluster access.