Welcome to ReleaseHub
ReleaseHub simplifies development by making the creation of environments easy
ReleaseHub makes it easy to manage environments so your team can focus on building value for your customers. ReleaseHub 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 ReleaseHub, 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 ReleaseHub do the rest.
- Allow for a common, consistent way to define and maintain applications and environments
ReleaseHub 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 ReleaseHub user interface.
ReleaseHub 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 ReleaseHub is to create ephemeral environments on every pull request to preview changes with stakeholders. Once you're using ReleaseHub, 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 ReleaseHub:
ReleaseHub 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.
ReleaseHub 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 ReleaseHub, you need a working Docker build and a
docker-compose.yml file that will run all the services you need.ReleaseHub 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, ReleaseHub will automatically detect them and provide you with options to build these services correctly. ReleaseHub manages all facets of creating environments and connecting frontends and backends together seamlessly.ReleaseHub 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 ReleaseHub, meaning you don't need to know anything about Kubernetes to use ReleaseHub.
To integrate your cloud provider with ReleaseHub, 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 ReleaseHub.
ReleaseHub currently supports AWS and GCP. Full support for other clouds will soon be available.
- 1.A
package.jsonfile containing abuildcommand in thescripts.
- 1.A working Docker build.
- 2.A definition of your application in a
docker-compose.yml. - 3.Your application's source code checked into a VCS such as GitHub or Bitbucket.
- 4.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.
- 5.Admin access to the AWS account where you'd like your environments to run.
ReleaseHub 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.
ReleaseHub 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 ReleaseHub 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.yamlfile found in your repository. - Automatically generate templates by parsing
package.jsonfiles for JavaScript applications. - Generate environment definitions from your Kubernetes YAML files.
- Generate templates from Helm charts.
ReleaseHub 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 ReleaseHub by creating a pull request in their VCS (version control system), which automatically creates an environment with the code changes in the PR.
Webhooks are calls made from your VCS back to ReleaseHub when certain events happen. This tells ReleaseHub there is something of interest to pay attention to in your repository, and kicks off automated workflows in ReleaseHub. ReleaseHub 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 ReleaseHub 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 ReleaseHub.
Applications and environments created with a ReleaseHub Starter Account are hosted in the ReleaseHub 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. ReleaseHub remotely manages the cluster and CDN so your teams can focus on building your applications.
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 ReleaseHub:
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 ReleaseHub environment versioning | Do not change the major version from which they were created and are not updated when the Application Template changes |
Last modified 3mo ago