How do I…

Develop against the cloud like it is production

The question every developer has before shipping is the same: "will this actually work in production?" The only honest answer comes from running the change against the cloud services it will run on. Wayfinder gives you a like-for-like environment: the same services as production, at a fraction of the size and cost, brought up when you need it and torn down when you're done.

⏱ 9 min read 🛠 Walkthrough ☁️ Real cloud · MCP · IDE

0 mocks of production between your code and real cloud

1 declaration. The same real services from dev through prod

~30 s code change to live against real cloud

MCP IDE and agent wired into the Wayfinder control plane

The story, in four steps

Container fakes of cloud services run on a developer's laptop so changes can be tested in seconds without waiting on cloud, but they quietly drift from the real services over time. The gap only shows up in staging or production, when it is hardest to fix. Wayfinder flips the order: real cloud from your first commit, the same way of working through to production, torn down when you are done.

The walkthrough

Why the "like-for-like" container trap is so seductive and so wrong, what to do instead, and the IDE workflow that makes real cloud from day one feel faster than mocking.

The bet behind every container fake of a cloud service is "the API is the same, so the behaviour is the same." It almost never is. As a concrete example, Wayfinder's own resource graph runs on Amazon Neptune in cloud and was first tested against a local Neo4j container. Same Bolt protocol, same openCypher driver, "should be fine." Two failures only ever appeared in cloud.

cypher · works in Neo4j, fails in Neptune Label wildcard %: a Neo4j extension, not standard openCypher

MATCH (this:OrgSystem {uid: $uid})-[l]-(that:%)
RETURN that
// ✅ Neo4j local: returns related nodes
// ❌ Neptune:     parse error: % is not openCypher

server config · default differed silently neptune_query_timeout shipped at 25 ms; Neo4j has no equivalent

neptune_query_timeout = 25     # ms, Neptune default in our cluster
                               # every non-trivial cypher query timed out
                               # local tests never hit it

Mean time to recovery grows. When a production issue can't be reproduced quickly against a like-for-like environment, recovery is delayed. Every hour spent trying to recreate the conditions production was in is an hour the issue is still live.
Divergent environments are costly to keep aligned. Maintaining and managing a different-shaped environment alongside production takes constant effort. It makes troubleshooting production issues harder when the local environment doesn't match, and it stops you validating against anything close enough to production to be a useful signal.
The shape of the environment hides real cloud behaviour. Object stores, queues, databases, identity and networking each behave differently in cloud than in a different-shaped local copy. Runtime, limits, IAM, eventual consistency and regional behaviour are all part of the contract, not just the API surface. The more cloud services your code touches, the wider the gap between what local tests can tell you and what production will accept.

Teams reach for technologies they can control themselves because the real thing has too much friction: tickets raised to the platform or DevOps team, week-long provisioning, no real access to environments to spot differences, long waits between asking and getting anything back. Wayfinder removes that friction. One manifest declares what you need, what consumes what and what scope each component runs at. The thing you bring up against dev is the thing you run in production.

Wayfinder.yaml · graph-backed service A real Neptune cluster, declared once, used by every environment

apiVersion: v1
name: graph-svc
components:

  resourcegraph:
    type: CloudResource
    plan: aws-neptune-cluster@1.0.0
    inputs:
      - name: shared
        value: true                # shared across environments
      - name: deletion_protection
        value: true

  api:
    type: CloudResource
    plan: aws-lambda-go-handler@1.0.0
    workloadIdentity:
      access:
        - to: resourcegraph
          consumptionPolicy: read-write
    inputs:
      - name: suffix
        value: graph-api

Short-lived credentials, only when they're needed. Vended to a developer's laptop when work is happening, or to CI when it runs, scoped to the resources the work needs and gone after. No long-lived credentials sitting on machines or in pipelines.
Plans wire everything up at runtime. When an environment comes up, the plan templates dynamically find the right resources for that environment and stack, wire up workload identities where they're needed, and resolve access between dependencies. Developers get a working stack without having to know how any of that plumbing happens.
One common interface, idempotent across environments. Wayfinder gives you a single, repeatable interface for declaring and bringing up cloud resources. The same manifest produces the same shape of stack every time, in every environment, so dev behaves the same way as production.
Your own instance of the stack, iterate against it like local. Production still ships through CI/CD, but anyone on the team can stand up their own working, production-shape stack on demand and iterate against it the way they would against a local setup. No queueing for a shared dev environment, no diverging from what production actually looks like.
One manifest, no long-lived environment branches. The same manifest runs dev through prod, so you don't need a branch-per-environment strategy in git. Every developer can stand up their own production-shape environment instead of holding a long-lived branch open, and the merge conflicts and stale-branch pain that come with that pattern stop being part of how you ship.

Some parts of a stack are expensive to recreate every time you iterate: a database loaded with test data, a Kubernetes cluster, anything stateful or slow to provision. Wayfinder lets you mark these resources as shared so the heavy components stay up across many instances of your stack. The ephemeral bits come and go as you work, the stateful and runtime bits stay, your test data persists, and the bill for non-production drops.

Wayfinder · multiple stack instances binding to shared resources A database and a Kubernetes cluster declared once, consumed by many stacks

wf use environment dev         && wf up -f Wayfinder.yaml -i alice-feature-x
wf use environment dev         && wf up -f Wayfinder.yaml -i bob-experiment
wf use environment preview     && wf up -f Wayfinder.yaml -i pr-1287
wf use environment integration && wf up -f Wayfinder.yaml -i nightly

# Each stack instance brings up its own ephemeral components
# (handlers, queues, function deploys) but binds to the same
# shared database and shared Kubernetes cluster, keeping test
# data warm between iterations and non-production cost low.

Lower non-production cost. A shared database, message broker or Kubernetes cluster is one bill instead of one per developer or per PR. The expensive resources stay up, the per-stack ephemeral bits bind to them on demand.
Test state persists between iterations. When you bring up a fresh instance of your stack, the shared database is already there with your data. No reloading fixtures, no waiting for restores, no losing where you got to.
Tear down only what should go. Handlers, containers and other ephemeral components tear down when you're done. The shared resources stay so the next iteration is seconds to bring up, not a fresh provision.
Works for data and runtime alike. Sharing isn't only for databases. A shared Kubernetes cluster, a shared event bus or a shared CDN can all be marked shared and consumed by many stack instances. Anything that's costly or slow to bring up doesn't need to be brought up again.

Wayfinder plugs into the way you already work. Your IDE and your AI agent connect to the Wayfinder control plane over MCP, the open protocol Claude Code, Cursor and the major agentic IDEs all consume. Queries and changes run under scoped identities the platform team controls, against the same live cloud you're developing against. The result is a development workflow that gives you honest answers in seconds, against real services, with full auditability of who did what.

~/.config/claude/mcp.json (or your IDE equivalent) Point your agent at the Wayfinder control plane

{
  "mcpServers": {
    "wayfinder": {
      "command": "wf",
      "args": ["mcp", "serve"],
      "env": {
        "WF_TENANT":      "${WF_TENANT}",
        "WF_WORKSPACE":   "${WF_WORKSPACE}",
        "WF_ENVIRONMENT": "${WF_ENVIRONMENT}"
      }
    }
  }
}

Cloud queries run as you. When you query cloud through your IDE, you do so with your Wayfinder identity. You can only see and act on what your team has granted you access to.
Platform-controlled agent identities, full auditability. Wayfinder agents run as their own scoped identities the platform team configures. AI tooling gets only the access it needs for the task, every action is auditable, and the risk of an agent doing something it shouldn't is contained.
Live cloud state, not stale snapshots. The agent reads actual resource state, and manifest changes (renames, access grants, splitting components) happen with knowledge of the live graph. No guessing.
Deployment AI converts what you already run locally. Point Wayfinder Deployment AI at your local setup and it scans what you're running (containers, services, databases, message brokers), maps each one to the CloudResourcePlans your platform team has published, and produces a Wayfinder.yaml that brings the same stack up against real cloud. The on-ramp is the AI doing the translation, not you rewriting your stack by hand.
Code change to live in seconds. Save and a new revision is running against the same shape of cloud as production. Open a PR and a preview environment comes up the same way, bound to the same shared resources.
One protocol, every editor. MCP is what major agentic IDEs consume. Today Claude, tomorrow Cursor, next year something else: the workflow follows you.

See it on your own stack

Book a 20-minute demo. We'll declare a real cloud service in a manifest, share it across two environments, wire the MCP server into an IDE, and have you change code against real cloud inside the call.

Book a demo More resources