Reference docs

Building & deploying


Begin isn't just responsible for provisioning and managing your app's serverless infrastructure, it's also a fully integrated CI/CD build pipeline optimized for serverless architecture.

Begin builds run entirely in cloud functions, so they spin up fast and run in parallel as quickly as you can push changes.

The Builds & Deploys view – your default view in Begin - shows all your app's builds, deploy status, and corresponding log data.

Begin screenshot

Deploying to Begin is as simple as pushing to master or cutting a git tag.

Deployments to staging and production take only seconds are instantly available at scale – enjoy the benefits of near-instant iteration with frequent pushes!

Build pipeline

Begin offers three hosted environments out of the box: testing, staging, and production. (Of course, Begin also supports full local development.)

Within these environments, Begin follows a fairly traditional CI/CD build pipeline:

  • testing - Commits to master kick off CI; green builds deploy to staging
  • staging - Runs latest green build from master; clicking the Deploy to Production button in the left nav in Begin (or cutting a git tag) deploys to production
  • production - Runs the latest production release

Deploying to staging

Each push to master kicks off Begin CI.

The last step for each green build is a staging deploy.

The current running version on staging is represented by the commit SHA, and can be found in the upper left corner of Begin.

Deploying to production

Deploys to production can only occur when the latest staging build is green. Cut a production release by:

  • Using the Deploy to Production button in the left nav in Begin, or
  • Creating a git tag, i.e.:
    git tag -a 1.0.1 -m "This release includes 20% more cowbell"
    git push origin 1.0.1
  • Or also by cutting a GitHub Release

The current running version on production is represented by the version you specified in your tag, and can be found in the upper left corner of Begin.

👓 Note: We strongly encourage the use of SemVer when creating production releases!

Configuring build steps

Begin CI executes three default, non-configurable steps: (verify, install, and deploy); and three optional, configurable steps: build, lint, and test. In order of execution:


Responsible for validating the repo payload from git and prepping Begin's infrastructure for a deployment.

This step is non-configurable and does not output logs.


Responsible for installing dependencies via NPM to all routes (e.g. src/http/**) and shared code (src/shared, src/views).

This step is non-configurable and does output logs.

Note: dependencies in your project's root package.json are not available to your routes.

To ensure a dependency is available to a given Function, cd into that function's folder and install it there.

To install global deps, install them to shared (src/shared) – but mind dependency bloat! Routes must weigh in under 5MB uncompressed.



Runs an arbitrary build script defined in your project's root package.json like so:

  "scripts": {
    "build": "./scripts/build"

This is a great place to generate static assets (to be deployed via the .static folder) or implement a bundler such as Webpack or Parcel.


Optional, but highly recommended!

Runs eslint by default (or the linter of your choice). Defined in your Begin app's default package.json (and for hopefully obvious reasons we strongly suggest not removing it):

  "scripts": {
    "lint": "eslint src --ignore-pattern node_modules --fix",


Optional, but highly recommended!

Defines your test procedures. Like lint, it's defined in your Begin app's default package.json (and we strongly recommend expanding your app's tests):

  "scripts": {
    "test": "NODE_ENV=testing tape test/*-test.js | tap-spec"


Ah, the step we've been waiting for!

Provided all other build steps exit(0), Begin takes over again to manage deployment, which primarily includes:

  • Deploying all routes to their corresponding Lambda cloud functions
  • Deploying static assets (.static/*) to your app's S3 bucket

The deploy step is non-configurable and does not currently output logs (but will in the future).