> For the complete documentation index, see [llms.txt](https://docs.zerve.ai/zerve-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zerve.ai/zerve-docs/self-hosting/aws-quickstart.md). # AWS QuickStart Run Zerve's compute and storage in your own AWS account, set up with a guided CloudFormation stack. The **AWS QuickStart** sets up [bring your own cloud](/zerve-docs/self-hosting/self-hosting.md#bring-your-own-cloud) in your AWS account. It opens an AWS CloudFormation stack that creates everything Zerve needs to run your code, store your data and host deployments in your account, then connects the account to your Zerve organization. ## Before you start You'll need: * To be an **organization admin** in Zerve * Permission to create CloudFormation stacks, IAM roles and networking in your AWS account * A **Zerve API key** from an organization admin. Create one in **Settings → Developer API**. See [Developer API](/zerve-docs/administration/developer-api.md). ## Set it up {% stepper %} {% step %} ### Open the QuickStart In Zerve, go to **Settings → Self-Hosting → AWS QuickStart**. This opens the CloudFormation stack in your AWS console, with your organization's ID already filled in. {% endstep %} {% step %} ### Fill in the parameters Fill in the stack's parameters, described below. Most have sensible defaults. {% endstep %} {% step %} ### Create the stack Create the stack. CloudFormation creates the resources in your account; see [AWS CloudFormation reference](/zerve-docs/self-hosting/aws-cloudformation-reference.md) for what's created. {% endstep %} {% step %} ### Wait for it to connect As the stack finishes, it reports back to Zerve with the details Zerve needs, and Zerve completes the setup on its side. Once the stack shows as complete, your organization's code runs in your account. If the stack can't connect to Zerve, for example because the API key is wrong, the stack fails to create, so you'll know straight away. {% endstep %} {% endstepper %} ## Parameters ### General | Parameter | What to enter | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Zerve organization ID** | Filled in for you | | **Zerve API key** | An API key from an organization admin, created in **Settings → Developer API** | | **Bucket name** | A prefix for the S3 bucket that stores Zerve's data. The bucket is named `-`. Default: `zerve-bucket`. | | **Apply common tags** | Tags every resource the stack creates with `zerve:owned` and `zerve:environment`. On by default. | | **Enable user-based auth** | **Not recommended.** Creates an IAM user with stored access keys, instead of the more secure role-based setup. Off by default; leave it off. | ### IAM | Parameter | What to enter | | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Permissions boundary** (optional) | An IAM policy to apply as the permissions boundary on every role the stack creates, if your organization requires one | ### DNS These set the web addresses of your deployed apps and APIs. | Parameter | What to enter | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Base domain** (optional) | The domain for your deployments, usually a subdomain of `zerve.cloud`, such as `acme.zerve.cloud`. **Without one, deployments may not be available.** | | **Hosted zone ID** (optional) | An existing Route 53 hosted zone for the domain. Leave blank to have the stack create one. Required if your domain isn't a subdomain of `zerve.cloud`; you'll also need to delegate the domain to it first. | With a base domain of `acme.zerve.cloud`, your deployments get addresses like `my-dashboard.app.acme.zerve.cloud` and `my-model.api.acme.zerve.cloud`. ### Networking | Parameter | What to enter | | -------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | **Existing VPC** (optional) | A VPC to use. Leave blank to have the stack create one. | | **Existing public and private subnets** (optional) | At least two of each, in different Availability Zones. Required if you choose an existing VPC. | | **Deployments' allowlisted IPs** | The IP ranges (CIDR blocks) allowed to reach your deployed apps and APIs | {% hint style="warning" %} **Deployments' allowlisted IPs defaults to `0.0.0.0/0`, which lets anyone reach your deployments.** Restrict it to your organization's IP ranges unless your deployments are meant to be public. {% endhint %} ## After setup ### Connecting to your databases Your code runs in private subnets, and its outbound traffic leaves through NAT gateways with **fixed IP addresses**. To let Zerve reach a database that only accepts approved IP addresses, add your account's NAT gateway IP address to the database's allowlist. If the stack created the VPC, find the address in your AWS console under **VPC → NAT gateways**. ### What Zerve can access Zerve manages the resources through a single IAM role, limited to resources whose names start with `zerve`. See [What Zerve can access in your AWS account](/zerve-docs/self-hosting/aws-access.md). ## Removing the stack Deleting the stack removes most of what it created. A few resources are kept on purpose, so DNS and networking aren't lost by accident. See [What's kept when you delete the stack](/zerve-docs/self-hosting/aws-cloudformation-reference.md#whats-kept-when-you-delete-the-stack). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.zerve.ai/zerve-docs/self-hosting/aws-quickstart.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.