Skip to main content

livecycle.yaml

Livecycle uses a configuration file, livecycle.yaml, to describe the process of building and running a playground environment.

livecycle.yaml can be defined in your repository settings (or during installation). Additionally, you can add the livecycle.yaml file in the repository root and Livecycle will read it during playground creation. When using this approach, it's possible to create and test different configuration for different branches.

Editor#

Using the playground creation wizard you can edit livecycle.yaml directly from the browser.

Using built-in templates for common applications#

You can use one of our built in livecycle.yaml templates to get started easily with common applications such as Gatsby or Next.js:

templates

Adding build environment variables#

To add a build environment variable, use the Add build environment variable button in the livecycle.yaml editor:

add build environment variable

If the variable contains sensitive information, you can encrypt it by toggling ENCRYPTED:

toggle encrypted

Reverse proxy rules#

Livecycle supports reverse proxy rules to enable directing relative URLs from your app into your deployed backend.

For example:

Your front-end applications uses the relative path of /api to fetch data from your backend which is hosted at https://www.example.com/.

For this example, create the following proxy rule:

proxy rule

The corresponding yaml is:

proxy:  rules:    - match: /api/(.*)      target: https://www.example.com/api/$1      action: rewrite      force: false

Examples#

Here's an example of a livecycle.yaml file for a Gatsby JAMStack application:

version: v1alpha1web:  build:    type: Dockerfile    dockerfile:      contents: |        FROM node:14-buster as build        RUN npm install -g gatsby-cli        WORKDIR /app        COPY package.json yarn.lock ./        RUN yarn        COPY . .        RUN gatsby build  output:    type: static    static:      path: /app/public

Annotated version#

# Version of the configuration fileversion: v1alpha1
# Define the service that will be loaded in livecycle web interfaceweb:  # Build section - defines how livecycle is going to build this project  build:    # List of environment variables to inject during build.    # When using Docker based build, these variables will inject as build arg    build_args:      # Environment Variable name      - name: MY_ENV_VAR        # Environment Variable Value        value: SOME_VALUE        # Whether the value of the environment variable is encrypted.        # See the section on secrets and variable encryption        encrypted: true    # Type of build definition, currently only Dockerfile is supported    type: Dockerfile    # Dockerfile build type configuration section    dockerfile:      # (Optional) path to Dockerfile, default to ./Dockerfile      path: ./Dockerfile      # (Optional) define/override Dockerfile contents.      # Can be use when project doesn't use Dockerfile      # or there's need for customization      contents: |        FROM node:14-buster as build        RUN npm install -g gatsby-cli        WORKDIR /app        COPY package.json yarn.lock ./        RUN yarn        COPY . .        RUN gatsby build
  # Output section, for defining how the project  # is going to be published and run on livecycle.dev  output:    # Type of the output artifact, can be static or image    type: static    # Static output configuration section    static:      # Path section      path: /app/public    # Image output configuration for running the container    image:       # Port of the container to expose the traffic on      defaultPort: 80
  # Proxy section, for defining the behavior of the playground router  proxy:    # List of routing rules, these rules will    # evaluated in-order with priority to rules with force: true    rules:      # Matching of a url, can use regex and capture groups      - match: /api/(.*)        # Target url to redirect/rewrite to, can use        # replacement expression of captured groups        target: https://some_service.com/api/$1        # Action to return, can be redirect/rewrite, default: rewrite        action: rewrite        # Force the rule - when force is false, request first        # is handled by the playground service and only when there is 4xx error        # the request will be handled by this router rule        force: true