How a 5-Person Team Cloned Production for Local Dev and Never Looked Back

Last month I watched a team of five ship a feature from a laptop to production in under two days. No Slack threads asking DevOps for help setting up a staging environment. No "it works on my machine" when the PM finally saw it. No three-week wait for QA to get access to a running build.

They used Ankra Stacks to clone a production-like environment onto a developer's laptop, iterate locally, push through CI/CD, spin up an on-demand staging environment, hand it to QA and the client for review, and promote to production. Same stack at every stage. Same config. Different variables.

This is the story of how they did it.

The team

Five people. One backend developer (Priya), one frontend developer (Amir), one DevOps engineer (James), a QA lead (Sofia), and a project manager (Tom). The client wanted a new recommendation engine that needed Redis for caching, PostgreSQL for persistent data, Typesense for search, and HashiCorp Vault and Consul for secrets management and service discovery. The kind of infrastructure that usually takes a week just to agree on the Helm values.

Monday morning: "I need all of this running on my laptop"

Priya's application runs natively in her terminal. She writes Go, she runs go run main.go, she hits endpoints with curl. That is her loop and she is fast at it. What she does not want is to also hand-configure Redis, Postgres, Typesense, Vault, and Consul on her MacBook.

She has OrbStack running, which gives her a local Kubernetes cluster out of the box. The Ankra Agent gets installed with a single Helm command:

1helm install ankra-agent oci://ghcr.io/ankraio/ankra-agent \
2  --set apiKey=YOUR_API_KEY

That is it. Her local OrbStack cluster appears in the Ankra platform. No tunneling, no port-forward hacks, no custom scripts.

Building the infrastructure stack

James, the DevOps engineer, had already built a production stack in Ankra for their main application. It included Redis, PostgreSQL, Typesense, Vault with Consul as the storage backend, ingress-nginx, and cert-manager. Priya does not need to understand any of that. She goes to Stacks, finds the production stack, clicks the menu, and selects Clone to Cluster, targeting her local OrbStack cluster.

1ankra cluster stacks clone production-infra --to priyas-orbstack

The stack arrives as a draft on her local cluster. She can review every addon and manifest before deploying. The stack variables automatically resolve to local values: the ingress domain switches from app.company.com to localhost, resource limits scale down to fit a laptop, and replica counts drop to 1.

She clicks deploy. Ankra's engine resolves the dependency graph, deploys the namespace first, then Consul, then Vault (which depends on Consul as its storage backend), then PostgreSQL, then Redis, then Typesense. Five minutes later, everything is running.

It works out of the box

Priya runs her application natively in her terminal with go run main.go. Her app connects to Redis on localhost:6379, Postgres on localhost:5432, Typesense on localhost:8108. OrbStack exposes Kubernetes services to localhost automatically, so there is no manual port-forwarding needed. No Docker Compose file. No kubectl port-forward running in five separate tabs. No "let me check if the ports conflict with something else." She writes code, saves, and her application talks to production-grade infrastructure running in Kubernetes on her own machine.

If services are not reachable on localhost, check that Expose services to local network devices is enabled in OrbStack settings.

The infrastructure is identical to what runs in production. Same Helm charts. Same configuration structure. Same dependency wiring between Vault and Consul. The only things that differ are the variables: domain names, replica counts, resource limits, TLS settings. The blueprint is the same.

Monday afternoon: The Redis authentication problem

Priya's app connects to Redis but gets an authentication error. The production stack requires a password, but she does not know what it is or where to set it.

She opens the Ankra AI assistant with Cmd+J and types:

"My app can't connect to Redis. I'm getting an auth error on my local cluster."

The AI assistant knows her cluster state. It can see the Redis addon, its Helm values, and the Kubernetes resources it created. It responds:

"Your Redis deployment has auth.existingSecret configured, pointing to a Kubernetes Secret called redis-credentials. This secret has a key redis-password that was auto-generated when the stack was deployed. You can retrieve it with:

kubectl get secret redis-credentials -n infra -o jsonpath='{.data.redis-password}' | base64 -d

Alternatively, you can set a known password by adding a stack variable REDIS_PASSWORD and mapping it in your Redis addon values."

She grabs the password, sets it in her .env file, and her app connects immediately.

The ingress class mismatch

But there is a second issue. She cloned the production stack, and production uses an ingress class called nginx-external for their cloud load balancer. Her local OrbStack cluster only has the default nginx ingress class.

She asks the AI:

"My ingress resources are not routing traffic. Everything shows as not found."

The AI responds:

"The ingress resources in your stack are configured with ingressClassName: nginx-external, but your local cluster only has the nginx ingress class available. You should update the ingressClassName in your stack's ingress manifests to nginx. You can do this with a stack variable:

Set a cluster-level variable INGRESS_CLASS=nginx on your local cluster, and update the ingress manifests to use ${{ ankra.INGRESS_CLASS }}. This way, each environment resolves to the correct ingress class automatically."

She adds the variable, updates the manifest, and traffic routes correctly. The AI caught what would have been an hour of debugging in kubectl logs.

This is the pattern that makes Stacks powerful for local development. You clone the production blueprint, and the AI assistant helps you identify the handful of values that need to change for your local environment. After the first clone, those variables are saved. Next time, it just works.

Monday evening: DevOps can help without leaving their desk

Priya hits a more complicated problem. Vault is not initializing correctly on her local cluster. She is not a Vault expert, and the logs are dense.

She messages James: "Vault is failing to start on my local. Can you take a look?"

James does not need to walk over to her desk, SSH into her machine, or ask her to copy-paste logs into Slack. He opens the Ankra platform, navigates to Priya's OrbStack cluster, and he is looking at the same infrastructure she is. He can see the Vault pods, their logs, their events, the Consul backend status, the Helm values. He opens a Pod Terminal directly in the Ankra UI, selects the Vault container, and drops into a shell.

He finds the issue: the Consul storage backend address in the Vault config has a hardcoded production namespace. He updates the Helm values in the stack to use ${{ ankra.CONSUL_NAMESPACE }}, sets the variable to infra on Priya's cluster, and redeploys. Vault starts.

Here is what matters about this interaction: James had full control over the Kubernetes environment on Priya's laptop, but he was completely isolated to the Kubernetes cluster. He could not access her filesystem, her code, her browser history. He operated inside the Kubernetes boundary and nothing else. For a small team where everyone wears multiple hats, this balance between helpfulness and isolation is critical. DevOps can unblock developers in minutes, and developers do not need to hand over their whole machine.

Tuesday morning: Push to GitHub, let CI handle it

Priya's feature works locally. Her Go application talks to Redis, Postgres, Typesense, and Vault, all running in her OrbStack Kubernetes cluster. Time to get it into the real pipeline.

She pushes her application code to a feature branch. Amir pushes the frontend changes to the same branch. Their GitHub Actions workflow kicks in:

1name: Build and Deploy
2
3on:
4  push:
5    branches: [feature/*]
6
7jobs:
8  build:
9    runs-on: ubuntu-latest
10    steps:
11      - uses: actions/checkout@v4
12      - uses: docker/build-push-action@v5
13        with:
14          push: true
15          tags: ghcr.io/company/recommendation-engine:${{ github.sha }}
16
17  update-gitops:
18    needs: build
19    runs-on: ubuntu-latest
20    steps:
21      - name: Clone GitOps repo
22        run: git clone [email protected]:company/gitops-config.git gitops
23      - name: Update image tag
24        working-directory: gitops
25        run: |
26          sed -i "s|image:.*|image: ghcr.io/company/recommendation-engine:${{ github.sha }}|" \
27            clusters/dev-cluster/manifests/recommendation-deployment.yaml
28      - name: Push to GitOps
29        working-directory: gitops
30        run: |
31          git add .
32          git commit -m "deploy: recommendation-engine ${{ github.sha }}"
33          git push

The GitHub Action builds the container image, pushes it to GHCR, and updates the manifest in the GitOps repository. Ankra detects the change in the connected Git repository and triggers ArgoCD on the dev cluster. The new image rolls out automatically.

This is the same GitOps flow the team uses for every service. The infrastructure stack (Redis, Postgres, Typesense, Vault, Consul) is already running on the dev cluster because James cloned the same production stack there weeks ago. Priya's application code deploys into that existing infrastructure. No new Helm values to write. No infra tickets to file.

Tuesday afternoon: On-demand staging

The feature works on the dev cluster. Now it needs to go to staging for formal testing. James clones the same infrastructure stack from the dev cluster to staging:

1ankra cluster stacks clone production-infra --to staging-cluster

The staging cluster has its own set of variables: staging.company.com for the domain, higher resource limits than local but lower than production, staging TLS certificates, a staging-specific Vault token. The stack arrives as a draft. James reviews the manifests, confirms the variable resolution looks correct, and deploys.

The application deployment follows the same pattern. The GitHub Actions workflow runs against the staging branch, updates the GitOps repo for the staging cluster, and ArgoCD syncs it. Within minutes, the recommendation engine is running in staging with the full infrastructure stack behind it.

Everything committed to Git. Every addon, every manifest, every variable override. If something goes wrong, they can diff staging against dev and see exactly what changed. No tribal knowledge required.

Tuesday afternoon: QA gets access

Sofia, the QA lead, needs to test the recommendation engine in staging. In the old world, this meant asking James to set up port-forwarding, share credentials, or create a VPN connection. That conversation alone could burn half a day.

With Ankra, James opens the organisation settings, clicks Add User, types Sofia's email, and assigns her the Member role. That is it.

Sofia logs in and sees the staging cluster. She can browse the running workloads, check pod logs, view the stack configuration, and access the application through the staging domain. She does not need kubectl. She does not need cluster credentials. She does not need to understand Helm charts.

She finds a bug: the search results are not returning in the expected order. She opens the Ankra AI assistant and asks:

"The recommendation-engine pods are returning search results in the wrong order. Can you check the Typesense configuration?"

The AI assistant examines the Typesense addon's Helm values, the pod logs, and the resource state. It identifies that the sort order configuration in the Typesense values differs from what the application expects. Sofia copies the AI's findings into a bug report and assigns it to Priya.

Tuesday late afternoon: The client sees it before production

Tom, the PM, has a demo with the client at 4pm. The client wants to see the recommendation engine working before they approve the production rollout.

Tom asks James to add the client to the platform. James opens the organisation settings, adds the client's email, and assigns them Read-only access.

The client opens the Ankra platform and sees the staging environment. They can view the application, see that the infrastructure is running, and verify the feature works as expected. They cannot modify anything. They cannot deploy. They cannot see secrets. They get just enough visibility to say "yes, ship it."

Tom does not need to record a demo video. He does not need to schedule a screen share. The client sees the live staging environment, running the actual code, backed by the actual infrastructure. They approve.

Wednesday: Production

The stack has been tested locally on Priya's OrbStack, validated on the dev cluster, verified by QA on staging, and approved by the client. Time for production.

James clones the stack from staging to the production cluster:

1ankra cluster stacks clone production-infra --to production-cluster

The stack arrives as a draft. Production variables resolve: the real domain, production TLS certificates, higher replica counts, production Vault tokens with tighter policies, production Consul ACLs. James reviews every manifest in draft mode. Nothing touches the production cluster until he clicks deploy.

The application deployment follows the same GitHub Actions flow, this time triggered by a merge to main. The image deploys, ArgoCD syncs, and the recommendation engine is live.

Total time from "I need this running on my laptop" to production: under two days. Four environments. One stack template. Zero YAML copying.

What made this work

Stacks as the unit of infrastructure. Not individual Helm charts scattered across repos. Not Terraform modules that take 30 minutes to plan. A Stack groups everything the application needs: Redis, Postgres, Typesense, Vault, Consul, ingress, certificates, namespaces. Clone the stack, and you clone the entire environment.

Variables at every level. Organisation defaults, cluster overrides, stack overrides. The same stack template runs everywhere. The domain name, the replica count, the ingress class, the resource limits are all just variables that resolve differently per cluster.

The AI assistant that knows your cluster. Not a generic chatbot. The AI sees your addons, your manifests, your Helm values, your pod logs. When Priya cloned the production stack and Redis auth failed, the AI did not give her a generic Redis troubleshooting guide. It told her exactly which secret to look at and exactly which variable to set. When the ingress class was wrong, it told her exactly which field to change and suggested the variable pattern to make it permanent.

DevOps access that is helpful and isolated. James could debug Vault on Priya's laptop through the Ankra UI. He had full control over the Kubernetes environment, pod terminals, logs, Helm values, redeployments. But he was sandboxed inside the Kubernetes boundary. He could not access Priya's code, her files, or anything outside the cluster. Full control where it matters. Complete isolation everywhere else.

Git as the source of truth. Every clone, every variable change, every deployment is committed to the GitOps repository. When Tom shows the staging environment to the client, there is a Git commit that represents exactly what is running. When they promote to production, they can diff the two and see exactly what changed. Auditors love this. Developers love this more, because it means they can understand any environment by reading a repo.

GitHub Actions as the CI glue. The team did not replace their CI pipeline. They kept GitHub Actions for building images and updating manifests. Ankra handles the infrastructure and the GitOps sync. The two systems work together without stepping on each other.

Clone, don't recreate

The real unlock is that Priya never built the infrastructure stack. James built it once for production. He had already cloned it to the dev cluster weeks earlier. Priya cloned it to her laptop. The AI assistant helped her adjust the two or three values that differ between production and a local environment. Then James cloned it to staging, and then to production. Each time the stack carried its dependency graph, its Helm values, its manifests. Each time the variables resolved for the target environment.

This is what "production-like" actually means. Not a docker-compose.yml that vaguely resembles production. Not a README with 47 steps to set up a local environment. The actual production stack, running on Kubernetes, with the actual dependency wiring, adjusted for local constraints through variables.

If your team is still copying YAML between environments, still writing setup guides that nobody follows, still asking "does staging have the same Redis version as prod?", try cloning a stack. It takes five minutes. And it works out of the box.

Join our community: Slack

Follow us on: LinkedIn, GitHub

Contact us: [email protected]