> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/background-concepts/how-release-works-in-great-detail.md).

# How Release works

This is a technical discussion of how Release environments as a service work (EaaS) when deployed into your cloud account. These examples generally refer to AWS, but Release offers full support for other cloud service providers.

## Step 1: Choose a base domain

Release environments are deployed underneath a subdomain for ease and isolation. For example, the subdomain `release.example.com` may have multiple environments that are reachable as `serviceA-envA.release.example.com` or `serviceB-envA.release.example.com`, and so on.

You can use wildcard domains for preproduction and production environments, so that for example, both `*.service-A-envA.release.example.com` and `*.staging.example.com` can be used. Wildcard domains can be used to accommodate different languages: `us.staging.example.com` or categories: `shoes.staging.example.com`.

A shopping website `shopping.com` may have an application called `shoes` and a customer called `buyer`. The customer's private application URL would be `shoes-buyer.release.shopping.com`. Custom domains, such as `shoes.buyer.com`, need [external DNS configuration](/guides-and-examples/domains-and-dns/external-dns.md).

In advanced configurations, preproduction applications can be deployed into one subdomain (`*.release.example.com`) and production or staging environments deployed directly as, for example, `www.example.com` or `staging.example.com`.

Configuration of your domain is handled in the `hostname` field of the [Application Template](/reference-documentation/application-settings/application-template/schema-definition.md).

## Step 2: Spin up a Kubernetes cluster

With Release, you can deploy environments and applications without in-depth knowledge of the infrastructure needed to run your application code.

When Release is integrated with your cloud service provider, it is given credentials and authorization to build infrastructure and deploy applications to your cluster.

* For AWS and GovCloud, a CloudFormation template creates an IAM role for Release.
* With GCP, a project credential file allows Release to build and deploy code to projects.

For EaaS customers, cloud integration is configured for each cloud provider account, so you can deploy across clouds and regions.

For private application customers, a landing page is designed for each installation that has access to your cloud account.

Given secure access to your cloud account, Release spins up all the necessary buckets, Kubernetes clusters, and supporting infrastructure. AWS uses several services including EKS, ECR, S3, Route53, VPC, RDS, DynamoDB, RDS, CloudFront, and ALB. GCP uses Container Engine, Container Registry, Google Cloud Virtual Network, Cloud Load Balancing, Cloud DNS, Cloud Storage, and Cloud SQL.

![An example diagram of an AWS Cloudformation template for an EKS cluster in Release](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-a873e4cb57f85c8c84c83bb397d455aa715fce06%2Ftemplate1-designer.png?alt=media)

## Step 3: Deploy an application

Release environments are built from an [Application Template](/reference-documentation/application-settings/application-template.md) that runs many versions of your application simultaneously in a complete stack so you can test and view multiple branches of code and ideas in parallel.

The production deployment of applications is straightforward because the development Application Templates vary only slightly in terms of [Environment variables](/reference-documentation/environment-settings/environment-specific-environment-variables.md). Since multiple production environments differ only slightly for individual customer needs, private application customers can run their own version of an application in their accounts for privacy, security, or regulatory requirements.

## Step 4: Request SSL Certificates

Release uses AWS Certificate Manager (ACM) with DNS validation enabled to issue secure SSL Certificates for applications. This process is clear if the subdomain is configured in Route53 in the same account and the zone is publicly available. In some cases, exceptions need to be made to validate the certificates manually:

* For AWS GovCloud accounts, Route53 has private-zone-only support. The Release UI generates the validation records to be inserted into the public zone to validate the certificate request. A DNS CNAME record is created and ACM then validates the certificate.
* Similarly, AWS or GCP accounts with private zones need to copy the validation records from the Release UI and create a DNS CNAME record in the public zone.
* In cases where public DNS zones do not exist, a fake public zone can be created to validate CNAME records. This is not recommended, but will work if the DNS domain is registered, owned by the end user, and valid. Release provides detailed support in these situations.

## Step 5: Configure access to your datastores and services

Release applications and environments deployed into your cloud account can be granted secure access to resources. The table below shows different ways to do this in AWS and GCP.

| AWS Access Resource | Method          | Release Support         |
| ------------------- | --------------- | ----------------------- |
| VPN                 | VPN Gateway     | Manually configured     |
| VPN/VPC Networking  | Transit Gateway | Automatic               |
| VPC Networking      | VPC Peering     | Manually configured     |
| RDS Instances       | VPC Peering     | Manually configured     |
| AWS Services        | Role Sessions   | Terraform, Pulumi, etc. |

| GCP Access Resource |                       | Release Support     |
| ------------------- | --------------------- | ------------------- |
| VPC Networking      | VPC Network Peering   | Manually configured |
| Cloud DB            | Instance Level Access | Manually configured |
| VPN                 | Cloud VPN             | Manually configured |

## Step 6: Monitor and maintain your applications

Release handles administration, support, and upgrades, and ensures smooth functioning of the infrastructure dedicated to running your applications. If you want more visibility into infrastructure for cost analysis, auditing, performance, or reliability reasons, there are several options available:

| Visibility Required                      | Vendors or Technologies                    | Release Support                    |
| ---------------------------------------- | ------------------------------------------ | ---------------------------------- |
| Application Performance Monitoring (APM) | Datadog, New Relic                         | Kubernetes Agents                  |
| Metrics Collection                       | Datadog, Cloudwatch, Stackdriver           | Kubernetes Agents and Integrations |
| Log Collection and Analysis              | Datadog, ELK, JournalD, Release UI         | Kubernetes Agents and Integrations |
| Kubernetes drivers                       | Lens, K9s, Kubectl, Eksctl, Cloudshell     | CLI and API                        |
| Shell access to Pods and Containers      | Lens, K9s, Kubectl, Cloudshell, Release UI | CLI and API                        |
| Alerting and Reporting                   | Datadog, New Relic                         | Kubernetes Agents                  |
| Network Traffic Analysis and Reporting   | Datadog, Thousand Eyes                     | Kubernetes Agents                  |

## Step 7: Customise your DNS entries

Release environments can be run on any valid zone if certificates and DNS records exist.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.release.com/background-concepts/how-release-works-in-great-detail.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.