LogoLogo
  • Welcome to Release
  • Getting started
    • Quickstart
    • Create an account
    • Prepare to use Release
    • Create an application
      • Create custom application
      • Create from template
      • Servers vs runnables
    • Create an environment
  • Guides and examples
    • Domains and DNS
      • Manage domains
      • DNS and nameservers
        • Configure GoDaddy
        • Configure Cloudflare
        • Configure Namecheap
        • Other DNS hosts
      • Routing traffic
    • Example applications
      • Full stack voting app
      • Flask and RDS counter app
      • Static site with Gatsby
      • Golang with Postgres and Nginx
      • WordPress with MySQL
      • Spring and PostgreSQL
      • Terraform and Flask
      • OpenTelemetry demo
      • Load balancer with hostname
      • Static JavaScript service
      • SSH bastion access to services
      • ngrok and OAuth for private tunnels
      • Using OAuth Proxy
      • Hybrid Docker and static site
      • App Imports: Connecting two applications
      • Example library
    • Running instances
      • Cron jobs
      • Jobs
      • Using Helm charts
      • Using terminal
      • Viewing logs
      • Troubleshooting
        • ImagePullBackoff error
        • CrashLoopBackoff error
        • Exit codes
        • OOM: out of memory
    • Advanced guides
      • Containers guide
      • Application guide
      • Kubernetes guide
      • Create a cluster
      • Upgrade a cluster
      • Managing node groups
      • Patch node groups
      • Hostnames and rules
      • Serve traffic on multiple ports
      • Configure access to your K8s cluster
      • Designing for multiple environments
      • Microservices architecture
      • Monitoring your clusters
      • Performance tuning
      • Visibility and monitoring
      • Working with data
        • Container-based data
        • Seeding and migration
        • Cloud-provided data
        • Golden images
        • Third party
      • Pausing Instant Datasets
        • Application pausing schedules
        • Pause/resume environments
      • Infrastructure as code
        • Terraform
  • Reference documentation
    • Account settings
      • Account info
      • Managing users
      • Build settings
        • Build arguments
        • Build SSH keys
      • Add integrations
      • View clusters and cloud integrations
      • Add datasets
      • Environment handles
    • Workflows in Release
      • Stages of workflows
      • Serial deployments
      • Parallel deployments
      • Rolling deployments
      • Rainbow deployments
    • Networking
      • Network architecture (AWS)
      • Network architecture (GCP)
      • Ingresses
      • IP addresses
      • Cloud-provided services
      • Third-party services
    • Release environment versioning
    • Application settings
      • Application Template
        • Schema definition
      • Default environment variables
      • GitHub
      • Pull requests
      • GitOps
      • Just-in-time file mounts
      • Primary App Link
      • Create application FAQ
      • App-level build arguments
      • Parameters
      • Workspaces
    • End-to-end testing
    • Environment settings
      • Environment configuration
      • Environment variables
        • Environment variable mappings
        • Secrets vaults
        • Using Secrets with GitOps
        • Kubernetes Secrets as environment variables
        • Managing legacy Release Secrets
    • Environment expiration
    • Environment presets
    • Instant datasets on AWS
    • Instant datasets on GCP
    • Instant dataset tasks
      • Tonic Cloud
      • Tonic On-Premise
    • Cloud resources
    • Static service deployment
    • Helm
      • Getting started
      • Version-controlled Helm charts
      • Open-source charts
      • Building Docker images
      • Ingress and networking
      • Configuration
    • GitOps
    • The .release.yaml file
    • Docker Compose conversion support
    • Reference examples
      • Adding and removing services
      • Managing service resources
      • Adding database containers to the Application Template
      • Stock Off-The-Shelf Examples
    • Release API
      • Account Authentication
      • Environments API
        • Create
        • Get
        • Setup
        • Patch
      • User Authentication
      • Environment Presets API
        • Get Environment Preset List
        • Get Environment Preset
        • Put Environment Preset
  • Background concepts
    • How Release works
  • Frequently asked questions
    • Release FAQ
    • AWS FAQ
    • Docker FAQ
    • JavaScript FAQ
  • Integrations
    • Integrations overview
      • Artifactory integration
      • Cloud integrations (AWS)
        • AWS guides
        • Grant access to AWS resources
        • AWS how to increase EIP quota
        • Control your EKS fleet with systems manager
        • Managing STS access
        • AWS Permissions Boundaries
        • Private ECR Repositories
        • Using an Existing AWS VPC
        • Using an Existing EKS Cluster
      • Docker Hub integration
      • LaunchDarkly integration
      • Private registries
      • Slack integration
      • Cloud integrations (GCP)
        • GCP Permissions Boundary
      • Datadog Agent
      • Doppler Secrets Manager
      • AWS Secrets Management
    • Source control integrations
      • GitHub
        • Pull request comments
        • Pull request labels
        • GitHub deployments
        • GitHub statuses
        • Remove GitHub integration
      • Bitbucket
      • GitLab
    • Monitoring and logging add-ons
      • Datadog
      • New Relic
      • ELK (Elasticsearch, Logstash, and Kibana)
  • Release Delivery
    • Create new customer integration
    • Delivery guide
    • Release to customer account access controls
    • Delivery FAQs
  • Release Instant Datasets
    • Introduction
    • Quickstart
    • Security
      • AWS Instant Dataset security
    • FAQ
    • API
  • CLI
    • Getting started
    • Installation
    • Configuration
    • CLI usage example
    • Remote development environments
    • Command reference
      • release accounts
        • release accounts list
        • release accounts select
      • release ai
        • release ai chat
        • release ai config-delete
        • release ai config-init
        • release ai config-select
        • release ai config-upsert
      • release apps
        • release apps list
        • release apps select
      • release auth
        • release auth login
        • release auth logout
      • release builds
        • release builds create
      • release clusters
        • release clusters exec
        • release clusters kubeconfig
        • release clusters shell
      • release datasets
        • release datasets list
        • release datasets refresh
      • release deploys
        • release deploys create
        • release deploys list
      • release development
        • release development logs
        • release development start
      • release environments
        • release environments config-get
        • release environments config-set
        • release environments create
        • release environments delete
        • release environments get
        • release environments list
        • release environments vars-get
      • release gitops
        • release gitops init
        • release gitops validate
      • release instances
        • release instances exec
        • release instances logs
        • release instances terminal
  • Release.ai
    • Release.ai Introduction
    • Getting Started
    • Release.ai Templates
    • Template Configuration Basics
    • Using GPU Resources
    • Custom Workflows
    • Fine Tuning LlamaX
    • Serving Inference
Powered by GitBook
On this page
  • Testing Docker Compose for Release
  • Building your application
  • Release ports and DNS hostnames
  • Environment variables

Was this helpful?

  1. Getting started

Prepare to use Release

PreviousCreate an accountNextCreate an application

Last updated 1 year ago

Was this helpful?

Take a look at to be sure you meet the requirements.

Release supports building and running complex applications. Release requires a docker-compose.yml, package.json, or .release.yaml file to be in the root of your application's Git repository. Release uses these files to generate the that is used as a blueprint to build your environments.

If your application has nested directories where your docker-compose.yaml or package.json files reside, you can add a .release.yaml file to the root of your repository to tell Release where these files are located. See reference guide for more information.

We recommend using a and a directory-per-service at the project root when your application requires two or more services. Here is an example directory structure for three services that require docker builds:

├── README.md
├── docker-compose.yml
├── result
│   └── Dockerfile
├── vote
│   └── Dockerfile
└── worker
    └── Dockerfile

If you're not using a monorepo, you can create an application for each repository and connect them using environment variables in each of those applications. See for more information.

Testing Docker Compose for Release

The best way to test if your application will run in Release is to get Docker Compose to run your application locally. See for more details.

Release allows you to quickly spin up containerized services without the traditional wait times involved with cloud-native services.

When running an application locally or in a Release ephemeral environment, we recommend that you isolate your application's external dependencies. Consider using off-the-shelf Docker images to represent the cloud-native services that your application depends on, such as Postgres, Redis, etc. Visit to find many off-the-shelf Docker images.

You can use environment variables to connect ephemeral environments to AWS-native services such as RDS, however, we recommend using these off-the-shelf Docker images to speed up deployment and simplify set up.

This is an example of a docker-compose.yml file that builds three Docker images and leverages two off-the-shelf containers for Redis and Postgres:

version: "3"
services:
  vote:
    build: ./vote
    command: python app.py
    volumes:
      - ./vote:/app
    ports:
      - "5000:80"
    depends_on:
      - "worker"

  result:
    build: ./result
    command: nodemon server.js
    volumes:
      - ./result:/app
    ports:
      - "5001:80"
    depends_on:
      - "worker"

  worker:
    build:
      context: ./worker
    depends_on:
      - "redis"
      - "db"

  redis:
    image: redis:alpine
    container_name: redis

  db:
    image: postgres:9.4
    container_name: db
    volumes:
      - "db-data:/var/lib/postgresql/data"

volumes:
  db-data:

Release detects many popular services such as Redis, MySQL, Postgres, RabbitMQ, and many more, and will handle opening standard ports for these services.

Here's an example of adding Redis, RabbitMQ, and Memcached with minimal configuration in Docker Compose:

version: "3"
services:
  redis:
    image: "redis:5-alpine"

  rabbitmq:
    image: "rabbitmq:3.7-alpine"

  memcached:
    image: "memcached:1.5-alpine"

Building your application

Specify the current working directory:

version: "3"
services:
  app:
    build: .

Specify a different directory to build:

version: "3"
services:
  vote:
    build: ./vote
version: "3"
services:
  mysql:
    build:
      context: .
      dockerfile: Dockerfile-mysql
      args:
        S3_BUCKET: "data.example.com"
        MYSQL_VERSION: "5.7"

Release ports and DNS hostnames

version: "3"
services:
  frontend:
    build:
      context: .
      dockerfile: Dockerfile-frontend
    ports:
      - "8080:8080"
    command: ["npm", "run", "dev-server-docker"]

In this example, Release creates a hostname for the frontend service that exposes port 8080.

Internal services, like your data stores, caches, and background workers, should not be exposed to the internet, and should only be available internally to other services defined in your docker-compose.

version: "3"
services:
  db:
    image: postgres:9.4
    ports:
      - "5432"

This example shows Postgres opening a container port on 5432 that another service can consume.

Environment variables

Most applications use environment variables to define how services talk to each other and/or change the behavior of an application in a given environment. Release uses the environment variables provided in your docker-compose as a starting point. All of the environment variables for each service defined in your docker-compose are loaded into Release when you initially create an application. Release supports all of the standard docker-compose mechanisms for defining environment variables.

version: "3"
services:
  api:
    build:
      context: ./api
      dockerfile: Dockerfile.django
    ports:
      - "8000:8000"
    env_file: .env

You can also set environment variables directly in your docker-compose file:

version: "3"
services:
  nginx:
    build: .
    ports:
      - "5000:5000"
    environment:
      - AWS_REGION=us-west-2
      - AWS_SECRET_ACCESS_KEY=XXX
      - RESOLVER=8.8.8.8

Release supports most options from . Release looks for all services with a build stanza, and executes a docker build for each service found.

Specify the Dockerfile and pass in :

Release uses the (HOST:CONTAINER) definition to determine when a service should be exposed to the internet. When Release encounters a service with a HOST:CONTAINER definition, it creates a NodePort, load balancer rule, and DNS hostname entry for the service.

You can use to specify an external env file:

If you have dynamic or secret environment variables, you can read more about in our reference guide.

docker-compose build
build arguments
docker-compose ports
env file
environment-specific environment variables
Application Template
The .release.yaml file
monorepo
Microservices architecture
Overview of Docker Compose
Docker Hub
what you need to use Release