Welcome to Release

Release simplifies development by making the creation of environments easy

What is Release?

Release makes it easy to manage environments so your team can focus on building value for your customers. Release can build environments in our cloud or yours, from the simplest applications (static JavaScript) to the most complex (microservices with many cloud-native dependencies).

Eliminate time spent managing environments

With Release, all of the management and tooling required to build a flexible environment ecosystem comes out of the box. You just connect your repositories, review your environment template and environment variables, and let Release do the rest.

Allow for a common, consistent way to define and maintain applications and environments

Release supports production and pre-production environments and every step is completely automated – from code push to environment creation. We track your source changes, then build new preview environments automatically for every feature, freeing you to focus on the things that matter.

Allow development teams a simple, easy way to reproduce environments for any reason

You can create an infinite number of development, staging, demo, and production environments without ever having to deal with the underlying infrastructure. These environments can then be automatically generated and updated whenever you push a code change or create a PR. They can also be manually deployed via the Release user interface.

Release enables:

Parallel environment infrastructure that removes software delivery bottlenecks.
Easy microservice development.
Integration of environments into developer workflows for a delightful developer experience.
DevOps teams to focus on high value work rather than building the same tooling over and over again.

In addition, organizations can create permanent staging and production environments and automate all of the steps, from code push to running in production.

A great way to get started with Release is to create ephemeral environments on every pull request to preview changes with stakeholders. Once you're using Release, you'll realize quickly there are many other use cases, including:

Easy local microservice development using cloud-based environments with microservice dependencies.
An alternative to your permanent staging environment infrastructure.
Ephemeral environments to test and preview changes with every pull request.
Scalable environments for performance testing.
Environments for developers to experiment with new infrastructure.
Sales demo environments.
On-demand environments for large migrations and testing.
Production environments based on Kubernetes.

When environments are simple to create, your teams will be enabled to move quickly without worrying about environments... ever.

Find out more about Release:

Static sites

Release supports standalone static sites running without Docker backends. These sites are pushed into a CDN and hosted on your behalf. See Static service deployment for more information.

Docker & Docker Compose

Release builds services running in Docker containers derived from your docker-compose.yaml file. Your application can have any combination of one or more services. For more information about creating an application that builds via Docker and Docker Compose, please see these useful reference guides from Docker:

In order to run Docker-based applications in Release, you need a working Docker build and a docker-compose.yml file that will run all the services you need.

Hybrid sites (static sites + Docker containers)

Release supports applications with both static frontends and other Dockerized services. Static applications are defined in a package.json file, while your other services are defined through a docker-compose.yaml file. When both these files are present in a repo, Release will automatically detect them and provide you with options to build these services correctly. Release manages all facets of creating environments and connecting frontends and backends together seamlessly.

Connecting to your AWS account

Release supports running environments in your AWS account through the creation of a Kubernetes cluster using AWS CloudFormation templates. This cluster will be fully and remotely managed by Release, meaning you don't need to know anything about Kubernetes to use Release.

To integrate your cloud provider with Release, you will need to go to Account Settings > Integrations where you will be walked through a simple set up procedure to connect your AWS account to Release.

Release currently supports AWS and GCP. Full support for other clouds will soon be available.

What you need to use Release

Frontend JavaScript applications

A package.json file containing a build command in the scripts.

Container-based applications

A working Docker build.
A definition of your application in a docker-compose.yml.
Your application's source code checked into a VCS such as GitHub or Bitbucket.
For OAuth-based VCS integrations (like Bitbucket), you'll need a user who has admin permissions on the repository to install webhooks and deploy keys. For GitHub, we use GitHub Apps and the app authorization handles the management of the repository.
Admin access to the AWS account where you'd like your environments to run.

How Release works

Release environments are built from an Application Template using default environment variables.

The Application Template defines the following high-level concepts:

The Kubernetes cluster your application is running in.
The domain where your application will be running.
Templates used to create ephemeral and permanent environments.
Hostnames where your application will be publicly accessible.
Resources allocated to your services.
Application services
Application workflows
Application jobs, such as running migration scripts.

Release can automatically generate these templates, or you can write them yourself from a library of examples for common frameworks. As a starting point, we recommend letting Release analyze your repository and automatically generate templates.

We currently support the following mechanisms to create your application templates and environment variables defaults:

Write your own templates from a library of examples for common frameworks and services.
Automatically generate templates by parsing the docker-compose.yaml file found in your repository.
Automatically generate templates by parsing package.json files for JavaScript applications.
Generate environment definitions from your Kubernetes YAML files.
Generate templates from Helm charts.

Release has been designed with minimal configuration in mind, but every application is unique and the application template allows developers to customize their application to suit their needs.

Developers generally interact with Release by creating a pull request in their VCS (version control system), which automatically creates an environment with the code changes in the PR.

Webhooks

Webhooks are calls made from your VCS back to Release when certain events happen. This tells Release there is something of interest to pay attention to in your repository, and kicks off automated workflows in Release. Release listens to webhooks for the following actions:

New pull request.
Closed pull requests.
Reopened pull requests.
Merged pull requests.
Code pushed to repository.

The user account that creates an organization's Release account must have admin privileges for the application's repository. See GitHub permissions and Bitbucket permissions for more information on setting up a repository to allow the proper webhooks for Release.

Where do applications and environments run?

Applications and environments created with a Release Starter Account are hosted in the Release cloud. If you have a Professional Account or higher, applications run on a Kubernetes cluster in your AWS account (optional) and static sites are hosted by CloudFront. Release remotely manages the cluster and CDN so your teams can focus on building your applications.

Comparing ephemeral and permanent environments

Ephemeral environments are environments that live for the duration of a pull request or are created manually. These environments will automatically track the branch from your pull request. An ephemeral environment is given a unique URL for each service. This allows developers to share work-in-progress development with stakeholders easily. Ephemeral environments are designed to be close replicas of production environments.

Permanent environments are environments that are not destroyed. Permanent environments are typically for more traditional staging or production workloads. These environments get static URLs that are based on the domain field in your Application Template. They can be set to track a branch and deployed automatically on a code push to your source control system, or they can be deployed manually.

In general, ephemeral environments and permanent environments are basically the same. However, there are some slight differences between the two that might affect which one you choose to use. These are a few of the differences between ephemeral and permanent environments when using Release:

Ephemeral environments	Permanent environments
Can be set to expire automatically, can be renewed during push event or manually Environment expiration	Never expire
Can be deleted easily	Require special checks to delete (contact support to find out how to delete them)
Can be automatically created by pull requests	Must be created manually
Are located lower down in the "Environment Details" page	Are always listed at the top of the "Environment Details" page
Cannot use a custom name and cannot be renamed	Must specify a custom name (contact support to rename environments)
Does not support rainbow deployments	Supports rainbow deployments
Covered only by normal support SLAs	Can be included in enhanced support SLAs (contact sales or customer success for more details)
Can specify overrides in the Application Template for ephemeral environments (adding/changing services and default resources) – this is the same for both, but there is a specific section for each type	Can specify overrides in the Application Template for permanent environments (adding/changing services and default resources) – this is the same for both, but there is a specific section for each type
Typically have fewer resources and extra container services for databases, Redis, etc.	Can be set with more resources and usually require more customisations from the default, usually exclude container services in favor of permanent infrastructure (like databases, Redis, queues, buckets, etc.)
Are created each time from the latest Application Template major version Release environment versioning	Do not change the major version from which they were created and are not updated when the Application Template changes

Ephemeral environments

Permanent environments

Can be set to expire automatically, can be renewed during push event or manually Environment expiration

Never expire

Can be deleted easily

Require special checks to delete (contact support to find out how to delete them)

Can be automatically created by pull requests

Must be created manually

Are located lower down in the "Environment Details" page

Are always listed at the top of the "Environment Details" page

Cannot use a custom name and cannot be renamed

Must specify a custom name (contact support to rename environments)

Does not support rainbow deployments

Supports rainbow deployments

Covered only by normal support SLAs

Can be included in enhanced support SLAs (contact sales or customer success for more details)

Can specify overrides in the Application Template for ephemeral environments (adding/changing services and default resources) – this is the same for both, but there is a specific section for each type

Can specify overrides in the Application Template for permanent environments (adding/changing services and default resources) – this is the same for both, but there is a specific section for each type

Typically have fewer resources and extra container services for databases, Redis, etc.

Can be set with more resources and usually require more customisations from the default, usually exclude container services in favor of permanent infrastructure (like databases, Redis, queues, buckets, etc.)

Are created each time from the latest Application Template major version Release environment versioning

Do not change the major version from which they were created and are not updated when the Application Template changes

NextQuickstart

Last updated 4 months ago