AWS one-click
Launch the self-hosted stack on EC2 with CloudFormation.
The AWS path is a CloudFormation stack that provisions a single EC2 host and runs the standard Docker deployment on it. You get the same stack as any other install; CloudFormation just handles the infrastructure and keeps the deployment updated.
What the stack provisions
One EC2 instance (Amazon Linux 2023, arm64, t4g.small by default, 20 GB
gp3 disk), an Elastic IP, a dedicated VPC with a security group opening
80/443 (or your existing VPC and subnet), an optional Route53 A record, and
an IAM role that allows SSM shell access. On first boot the instance writes
the deploy files to /opt/proliferate/server/deploy and runs the same
bootstrap.sh described in
Docker on any server. The stack sets
PROLIFERATE_TELEMETRY_MODE=self_managed for you, and because the default
instance types are all Graviton (arm64), it defaults to the aarch64 runtime
build from the matching release.
Template parameters
The template is server/infra/self-hosted-aws/template.yaml. The parameters:
| Parameter | What it does |
|---|---|
ReleaseVersion | The release to run, unprefixed (for example 0.3.0). Sets the server image tag and downloads the matching runtime binaries from the server-v<ReleaseVersion> GitHub release. |
SiteAddress | Public hostname for the server. Required unless UseSslipFallback is true. Point DNS at the Elastic IP. |
UseSslipFallback | Evaluation mode: derive the hostname from the Elastic IP as <ip>.sslip.io, so you can launch with no domain at all. |
CreateRoute53Record / HostedZoneId | Create the A record for SiteAddress in a Route53 hosted zone you own. Cannot be combined with the sslip fallback. |
ExistingVpcId / ExistingSubnetId | Reuse an existing VPC and public subnet instead of creating dedicated ones. Set both or neither. |
AllocateElasticIp | Allocate and attach a dedicated Elastic IP (default true). |
InstanceType | t4g.small (default), t4g.medium, or t4g.large. |
PostgresPassword / JwtSecret / CloudSecretKey | Leave blank to auto-generate and persist on first bootstrap, exactly like the Docker flow. |
GitHubOAuthClientId / GitHubOAuthClientSecret | Optional GitHub sign-in for desktops. Without them, desktops sign in with email and password. |
ServerImageRepository | Image repository, default ghcr.io/proliferate-ai/proliferate-server. Private ECR mirrors are supported. |
RuntimeBinaryUrl / RuntimeBinaryChecksumUrl | Overrides for the runtime binary tarball and its checksum file. Leave blank to use the matching release assets (the aarch64 build, matching the Graviton instance types). |
E2BApiKey / E2BTemplateName | Optional, for the cloud sandboxes add-on; the base install launches with no E2B configuration at all. Set both or neither: your E2B API key and the value the template build printed, for example proliferate-runtime-cloud. The template must be one you built in your own E2B team; E2B has no public templates. See E2B & sandbox template. |
Launch
Launch the template
Launch the CloudFormation template and fill in the stack parameters. For a
production install, set SiteAddress and point DNS at the Elastic IP (or let
the stack do it with CreateRoute53Record). For a quick evaluation, set
UseSslipFallback to true and leave SiteAddress blank; the stack serves
real HTTPS on an <elastic-ip>.sslip.io hostname with no domain and zero DNS
setup.
Screenshot: AWS Console, CloudFormation Create Stack parameters form
The Create Stack form with ReleaseVersion, SiteAddress, and the secret parameters left blank for auto-generation.
Launching from the CLI? The template is larger than CloudFormation's
51,200-byte limit for inline template bodies, so
aws cloudformation create-stack --template-body file://... fails with a
size error. Upload the template to an S3 bucket and pass --template-url
instead:
Wait for CREATE_COMPLETE
Bootstrap runs automatically on first boot. The stack sets
PROLIFERATE_PUBLIC_HEALTHCHECK_URL itself, so CloudFormation only reaches
CREATE_COMPLETE once the advertised HTTPS endpoint actually responds
(20-minute timeout).
Stack outputs:
| Output | What it is |
|---|---|
BaseUrl | The public HTTPS URL your deployment is live at. |
SiteAddress | The hostname in use (your domain, or the sslip.io name). |
SetupClaimUrl | The /setup claim page. Open it in a browser with the setup token to create the admin account; it returns 404 once the instance is claimed. |
ReadSetupTokenCommand | A ready-made SSM command that prints the one-time setup token (available only while the instance is unclaimed). |
ElasticIp / PublicIp | The IP serving the deployment. |
InstanceId | The EC2 instance id. |
SsmStartSessionCommand | A ready-made aws ssm start-session command to open a shell on the host. |
Screenshot: AWS Console, stack Outputs tab showing BaseUrl, SetupClaimUrl, and ReadSetupTokenCommand
The Outputs tab after CREATE_COMPLETE with SetupClaimUrl and ReadSetupTokenCommand highlighted.
Get the setup token and claim your instance
Once the stack reaches CREATE_COMPLETE, run the command from the
ReadSetupTokenCommand output. It opens an SSM session that prints the
one-time setup token and exits:
The token also appears in /var/log/cfn-init-cmd.log on the host, and you
can always reprint it with the Docker flow's health gate: open a shell with
the SsmStartSessionCommand output, then
cd /opt/proliferate/server/deploy && sudo ./wait-for-health.sh.
Terminal capture: SSM session running the ReadSetupTokenCommand and printing the setup token
A terminal running the stack's ReadSetupTokenCommand output with the setup token visible.
Open the SetupClaimUrl output in a browser and enter an email, a password,
an optional organization name (blank derives one from your email domain), and
the token. That account becomes the owner of the instance organization, and
the page returns 404 forever after.
Connect the desktop app
Point desktop apps at the stack's BaseUrl. See
Connect the desktop app.
Updating
Update the stack with a new ReleaseVersion parameter value. The instance
runs cfn-hup, which polls the stack metadata every few minutes, notices the
change, and runs update.sh in place (pull the new image, run migrations,
restart the stack). No shell access needed for routine updates.
You can also update manually: open an SSM session and run
cd /opt/proliferate/server/deploy && sudo ./update.sh. Both paths are the
same script.
See Updates & versioning for pinning strategy.