What we shipped, and what we're building.

A Step Functions state machine definition has to reference the exact names of the Lambda functions it calls — and those names are generated at deploy time by CloudFormation, so hand-typing them is guesswork that fails only after you deploy. Now, when you connect Lambdas to a Step Functions node, the exact deploy-time name of each connected function is listed directly above the Definition field, each with a copy button. Copy, paste into your state definition, deploy. No digging through generated templates, no broken references discovered twenty minutes into a stack create.

Try it: connect two Lambdas to a Step Functions node and open its Definition field.

Draw a line from a Lambda to a DynamoDB table and that one line can mean two very different pieces of infrastructure: an IAM policy that lets the function read and write the table, or a DynamoDB stream that triggers the function on every change. Until now you picked between them in the properties panel after connecting — easy to skip, and the default wasn't always the one you meant. Now the choice surfaces the moment you draw the edge: a small dialog asks which relationship you want, and the engine generates the right resources immediately. The template you export matches the diagram you drew, with no silent defaults in between. The same connect-time prompt covers every ambiguous pair on the canvas, not just Lambda-to-DynamoDB.

Try it: drop a Lambda and a DynamoDB table on the canvas and connect them.

Fixes & improvements

• •Properties panel widened so long resource names no longer truncate

We got lost in our own properties panel. Building a stack for a test run, we could not find where to set a DynamoDB partition key — it sat mid-list under a friendly label, looking exactly like every optional field around it. If the people who wrote the panel can lose a required field, you were losing them too. So the panel now knows what is required: every field whose absence produces a deploy-blocking error carries a Required badge and sorts to the top of its section, where you actually look first. And every field now shows its internal property key in small monospace next to the friendly label. Error messages and findings say hashKey; the panel used to say only Partition Key. Both names are now visible on the same row, so the message you read and the field you need to fix finally point at each other.

Try it: drop a DynamoDB table on the canvas and open its properties panel.

Fixes & improvements

• •The Advanced settings grouping now exists in Advanced mode too, expanded by default — it was previously one flat, undifferentiated list
• •New DynamoDB tables flag a missing partition key instead of silently pre-filling one; an unedited table still exports with a working default

Last week we certified the catalog — lint-clean output, required properties and IAM wiring verified, all of it gated in CI. Today we held the 12 starter templates to the only bar that finally matters: does CloudFormation actually build the stack? So we deployed them against a real AWS account — 44 live deployments across seven rounds in a single day. The first round was humbling: 4 of 12 made it through. Every template in that round passed lint and certification, and 8 still failed at create time — which is exactly why we did this. Lint-clean and deployable are not the same thing. Each failure got a fix-case recording the exact template we deployed, the resource that failed, and AWS's verbatim error; then we fixed, regenerated, and redeployed — 13 distinct defect classes fixed over the day — until the final round ended with all 12 templates reaching CREATE_COMPLETE, and every stack deleted cleanly afterwards. The whole day of live testing cost under $15 in AWS charges.

To be precise about what runs where: these deployments are a manual harness against a live account. CI still guards every change with the static certification checks — but as of today, the templates it guards are ones that have each built a real stack.

Try it: start a project from any of the 12 templates and export the CloudFormation.

Billing is on, and the free tier is real: 2 projects, 30 nodes per canvas, and 25 exports a month, with CloudFormation output in both JSON and YAML. Pro is $39 a month for individuals — unlimited projects and exports, the full service catalog, a live monthly cost estimate, security findings detail, and Git/PR export. Team is $129 a month flat for up to 10 people, with team collaboration on shared projects. Flat means flat: the tenth person costs the same as the second, because per-seat pricing punishes exactly the thing we want you to do — add the colleague who will actually deploy the stack. We kept the free tier honest for the same reason: you should be able to design something and export working CloudFormation before we ever ask for a card.

Try it: the pricing page has the full plan comparison.

Fixes & improvements

• •Sign in with Google, at both sign-up and sign-in
• •The sign-in page now surfaces OAuth redirect errors instead of silently bouncing you back

Until now, the only way to show someone your architecture was a screenshot. That was backwards — showing your work is the whole point of a diagram — so sharing is free, on every plan. Every project can now mint a public read-only link: create, copy, and revoke it from the dashboard. Anyone with the link sees the real canvas — pan, zoom, the actual node components, not a flattened image — and cannot edit anything. Revoke the link and it goes dead immediately; creating a new one rotates the address, so an old URL someone saved stops working.

Security findings detail is a Pro and Team feature — Free sees the counts, and deploy-blocking error checks stay free for everyone. Here is why it exists: a diagram can look reasonable and still describe something you would not run in production — a bucket with public access open, a security group that admits the entire internet, a data store with encryption switched off. The canvas now validates continuously while you edit. Nodes with problems get a red or orange badge; clicking a badge opens the findings panel filtered to that node, and clicking a finding selects and centers the node it refers to. The security checks cover public S3 buckets, world-open security group rules, unencrypted data stores, IAM policies with wildcard actions or resources, and publicly accessible databases.

Try it: open a project, click Share, and send the link to someone.

Fixes & improvements

• •Press Ctrl+K (Cmd+K on Mac) on the canvas to search the catalog and place a service from the keyboard — same auto-wiring and companion resources as a drag
• •Optional email verification from the dashboard banner; nothing is locked behind it

A service on the canvas only counts if the template it exports deploys. So certified means something specific here: the service has its own generator module, the CloudFormation it produces passes cfn-lint, required properties and IAM wiring are verified, and those checks run in CI on every code change. We just audited the entire catalog against that bar. 50 services clear it — and the count has only grown since; the homepage shows the live number. The 32 preview services that could not export a deployable template came off the palette entirely — we would rather the catalog be smaller and true than large and decorative.

The 12 starter templates got the same treatment: CI now re-checks all 12 with cfn-lint plus our certification rules on every code change, so a template that worked yesterday cannot quietly rot. Each template also ships with its own step-by-step deployment guide.

Try it: start a new project from any of the 12 templates.

Fixes & improvements

• •SSM Parameter Store, Step Functions, and EFS rebuilt from preview stubs into fully certified services
• •ACM certificates and Route 53 DNS join the catalog as certified services