Astro SSR + Supabase auth
Server-rendered Astro with sign in, sign up, and password reset wired to Supabase. Serves behind CloudFront with the SSR function on Lambda and API Gateway. Configuration reaches the app at boot from AWS Secrets Manager.
Early access. Free tier, no credit card.
Sign in with GitHub and pick a template. Emergy creates an AWS account just for you and deploys the app from your own repo. Dev and prod URLs, managed from one workspace.
your repo, on your GitHub · a real AWS account per user · OIDC deploys, no static keys
The same timeline streams in your workspace while it runs.
Sign up, then what
Every step below is visible in your workspace as it runs. Nothing happens behind your back.
Sign in with GitHub
youOAuth only. Nothing to install, no credit card. You land in an empty workspace.
You get a real AWS account
EmergyCreated through AWS Organizations while you watch the job run. It holds your infrastructure and secrets, isolated from every other user.
Create a repo from a template
youOne click opens GitHub's own Use this template page. The repo is created in your GitHub account and stays yours.
Provisioning starts by itself
EmergyThe GitHub App spots the new repo, links it to your workspace, writes the deploy variables, and dispatches the first workflow.
Actions deploys dev and prod
your repoTerraform, build, deploy. All of it runs in your repo, into your AWS account, and streams back to the workspace.
From then on it is routine: push to deploy, promote any build by SHA, add a domain, set secrets. All of it from the workspace, all of it running in your repo and your account.
Access
We do not want your data. Emergy never reads your code, never sees your secret values, and never touches your traffic. It gets only what deploying needs, and here is that list in full.
One file in your repo
The GitHub App has a single-file read permission for .emergy-cloud/config.json, the manifest that describes the project. It can read nothing else.
Repo variables and environments
It writes deploy configuration (account id, role, hostnames) as plain repo variables you can read next to your code.
GitHub Actions runs
It dispatches the build, deploy, and infrastructure workflows in your repo, and reads their status.
Deployment status and metadata
Repo names, workflow results, and environment URLs, so the workspace can show you what is live where.
Your code
No content read or write permission, by design. Builds happen in GitHub Actions, inside your own repository.
Your secret values
Secrets live in AWS Secrets Manager in your account. The platform stores key names only, to warn you when one is missing.
Static AWS keys
Deploys assume a scoped IAM role through OIDC at run time. Credentials expire in minutes and never sit in repo secrets.
Your traffic
The deployed app serves from your AWS account behind your CloudFront. Nothing proxies through Emergy.
Templates
Each template carries its own Terraform and workflows. You can read every line of what will run in your account.
Server-rendered Astro with sign in, sign up, and password reset wired to Supabase. Serves behind CloudFront with the SSR function on Lambda and API Gateway. Configuration reaches the app at boot from AWS Secrets Manager.
Plain Astro on S3 behind CloudFront. No server, no database, same pipeline. Good for marketing sites, docs, and anything that builds to files.
.emergy-cloud/config.json, is all Emergy reads Workspace
Folders in your workspace are AWS Organizations OUs, one to one. Accounts hold projects, projects hold environments and domains. What you see in the tree is what exists in the cloud.
Terraform, build, and deploy steps stream into the project page. No console tab needed to know what is running.
Every build is stored by commit. Deploy any of them to any environment; rolling back is deploying an older one.
Managed Route 53 zone or your own DNS. ACM certificates requested and validated for you, per environment hostnames wired in.
Set keys from the app into Secrets Manager in your account. The platform keeps names, never values.
Plans
Tiers change limits, never the pipeline or the access model. Upgrading is one Stripe checkout from the billing page.
For the first project
For real workloads
For lots of projects
FAQ
Something else on your mind? Sign in and look around; the free tier is the fastest tour.
You watch your AWS account being created. It takes a couple of minutes and every step is shown as it runs. When it turns green, you pick a template and create your first repo.
A real account, created for you inside Emergy's AWS Organization and used only by you. Your infrastructure, certificates, and secrets live in it, isolated from every other user. You don't bring an AWS bill; usage is part of your plan.
No. The GitHub App has a single-file permission for .emergy-cloud/config.json, plus access to Actions, repo variables, environments, and deployment status. It cannot read or write anything else in the repository. Builds run in GitHub Actions inside your own repo.
In AWS Secrets Manager, in your account, one secret per environment. You set values from the app, the platform never stores or logs them, and the deployed app loads them at boot. The workspace shows key names only.
Terraform in your repo creates the stack: S3 and CloudFront for the static template, plus Lambda and API Gateway for the SSR template. ACM certificates and Route 53 records are added when you attach a domain. An IAM role with an OIDC trust limited to your repo does the deploying.
Nothing. The free tier includes one AWS account and two environments per project, with no credit card. Pro adds more accounts and a staging environment; upgrade from the billing page when you need it.
Yes, cleanly. The repo already lives in your GitHub account with the Terraform inside it, and you can destroy a project's infrastructure from the app at any time. Nothing in the code depends on Emergy at runtime.
Sign in, watch your AWS account come up, and put a template live. It takes minutes and costs nothing.
early access · free tier · your repo, your account