Skip to main content
SurelyPlaced was running one product across several vendors. The application was on Vercel. Other pieces were already on AWS. The database was on Neon. Model calls went out to OpenRouter. Each part had its own deploy, its own dashboard, and its own bill. The AWS account already had credits on it. Those credits only covered what was actually running in that account. The Vercel deploy and the Neon database sat outside that bill, so the credits could not pay for them. A small change could mean a Vercel deploy, a database change somewhere else, and a separate look at whatever was already on AWS.

​
Before

Vercel

The application was deployed outside the AWS account.

Neon

The database sat with a separate provider, on a separate bill.

AWS

Some of the product was already in AWS, apart from the rest of the deploy.

OpenRouter

Model calls left the rest of the stack for another vendor.
There was no single environment. Production was the sum of those vendors. Finding where a request had failed meant checking more than one place, and the credits on the AWS account stayed unused by the parts that were not in it.

​
What changed

SurelyPlaced connected the AWS account they already owned. Connect AWS gives a CloudFormation link. They launched that stack themselves. Springwinter does not create the stack. The stack makes one role, and they choose what that role is allowed to do. They then moved the running application into one project. The web server, workers, site, and database are created in that account and share its network. A push to GitHub builds in the account and deploys there. Logs, metrics, and cost are read from the same resources. The application code that calls a model can still call out. What changed is where the product runs. The server, the background work, the site, and the database are no longer a Vercel project plus a Neon database plus a leftover slice of AWS. They are one deployment environment.

​
Credits and the bill

Those resources are AWS resources. The compute, the database, the cache, the buckets, and the distribution show up on the AWS bill for that account. Credits already on the account apply to that spend. There is no second infrastructure bill for the parts that used to live on Vercel and Neon. Springwinter reads cost from the account when you open it. It does not keep a separate copy of the application data, and it does not keep the temporary keys from a role assumption.

​
One place to deploy

Before, a release was a tour of vendors. After, a release is a build from the GitHub repository they connected.
1

Connect the account

Launch the CloudFormation stack in the AWS account that holds the credits. The role trusts Springwinter for that connection only.
2

Connect GitHub

Install the GitHub App and choose the repository. The build runs in the account. The install token is minted when a build starts and is not stored.
3

Put the pieces in one project

A web server, a worker, a static site, and a database share the project and the role. A branch can run as a preview with its own URL before it replaces the live service.
4

Watch it in one place

Build output, process logs, CPU and memory, and the estimate so far are read from the account for that resource.

​
In the account

One project

The pieces share a project, a network, and the role the account owner chooses.

GitHub deploys

The build runs in the account when the repository changes.

Database

PostgreSQL or MySQL on Amazon RDS, next to the services that use it.

Your AWS bill

Spend for these resources is the AWS bill, which draws on the credits in the account.