1. Home
  2. Introduction

What is webapp.io?

Webapp.io is a hyper-optimized DevOps platform for webapps.

We build testing VMs in seconds every time you push code to GitHub, GitLab, or BitBucket.

  • Our VMs automatically hibernate when they aren’t being used
  • We let you duplicate VMs to make copies of your stack and run acceptance tests in parallel
  • We take snapshots of the VM as it builds, so that future builds can entirely skip docker pull or npm install

What happens when I sign up?

  1. You’ll install webapp.io onto a GitHub, GitLab or BitBucket repository
  2. Our onboarding will guide you to build a Layerfile which defines your VM build
  3. You commit your Layerfile, and we’ll automatically build it into a VM every time you push a commit.

What can serverless VMs be used for?

Our users primarily use serverless VMs for three things:

  1. Preview environments - by making a Layerfile with the EXPOSE WEBSITE directive, you immediately get an environment deployed for every pull request.
  2. Acceptance tests - by making a Layerfile with SPLIT 5, you can build your stack and fork it five times to run tests in parallel.
  3. Hosting - by using Prioritize Snapshot, you can make ephemeral environments stick around and not shut off.

At webapp.io, we’re building a serverless VM platform. You can even create multiple Layerfiles and combine them into powerful DevOps workflows to help your team ship 10x faster.

Comprehensive step-by-step tutorial

1. Fork Example Repo

Go to the GitHub repository for the Livechat example and fork the repository.

Screenshot of the Livechat Example repo

Screenshot after clicking on the button in GitHub to fork the repository.

2. Clone To Local

Clone the new Livechat Example repository to your local machine.

Click on the “Code” button to get the URL to clone locally.

Shell

3. Sign up to webapp.io

Sign up to webapp.io and install webapp.io on your GitHub account, ensuring that webapp.io has access to the repository you created.

Screenshot of the sign-up page for webapp.io

Screenshot of the installations buttons on webapp.io

4. Make a Local Change

Make a change to the project locally, and push your changes to the repository you created.

5. View Website

Go to your dashboard on webapp.io to see your run, click on “Details”,“main-layerfile”, then “View website”.

Click on “main-layerfile” here, followed by “View Website”.

6. View Preview Environment

Wait for the server to start, you’ll be redirected to a preview environment with the Livechat Example.

That’s all you need to view the full-stack preview environment with webapp.io! Next, try making another change to one of the views (i.e., in /services/web/src/views/login/login.js) and push a new commit to see another preview environment with your changes.

Quickstart

To view the power of preview environments in action, let’s go through an example with our open-source version of Slack, Livechat Example, that uses Docker Compose. For the purpose of this quickstart guide, the codebase is monorepository, so all of the services are within a single folder (/services).

Our Livechat Example contains the following within the /services folder:

  • /api (our api to handle all requests)
  • /cypress (for running tests)
  • /migrate (for populating our database)
  • /web (our React frontend)

Most importantly, in the root directory, we have our Layerfile which is a set of instructions that tells webapp.io how to install, build, and run the Livechat Example. This Layerfile for our Livechat example is shown below:

Layerfile

View a Preview Environment for the Livechat Example

Limits

General Limits

The following general limits are applied to all Webapp.io accounts to prevent abuse.

-StarterTeamEnterprise
Team members per organization10UnlimitedCustom
Number of Layerfiles createdUnlimitedUnlimitedUnlimited
Preview Environments
Snapshots of Environments150Custom
CI/CD
Concurrent builds per organizationNone12Custom servers

If your project is likely to exceed these limits, please contact sales to discuss solutions.

Domains

StarterTeamEnterprise
Domains per organizationUnlimitedUnlimitedUnlimited

Snapshots & Snapshot Retention

A snapshot is a copy of a virtual machine at a specific moment in time. Snapshots help to load environments and configurations so that you can skip running steps that have not changed or that have successfully executed on previous commits.

Algorithm for Deleting Snapshots

Listed below is a summary of how we delete snapshots. It’s important to review this to learn the states of snapshots at different times.

  1. Split important snapshots into VIP, Important, and Not Important (VIP as the top tier).

Important Snapshots:

  • Newer than 10 minutes
  • Newer than a week old and the latest snapshot for an instruction
  • Newer than a week old and contains the EXPOSE WEBSITE instruction for an open pull request.

VIP Snapshots:

  • 30 prioritized snapshots per paying customer as determined by tier and how recent the snapshots are
  1. Order Snapshot Importance (VIP, Important, Not Important)

  2. Delete Snapshots

Delete Process:

  • Delete the oldest not important
  • Delete the oldest important
  • Delete the oldest VIP

Environmental Lifecycle

Environments (Layerfiles with EXPOSE WEBSITE, Layerfiles that expose a debug terminal, etc.) have three lifecycle levels:

  • Deleted, which means you can’t start them without rebuilding (rebuilding deletes everything, like your temporary database, registered user, and state in the environment).
  • Stopped, which means you see a spinner as they start - Running, which means it’s currently running

Running to Stopped

The Running lifecycle to Stopped lifecycle happens for a few reasons:

  • After 3 minutes of inactivity if there are builds queued
  • After 60 minutes in general (this can be changed by our admin team if requested)

Stopped to Deleted

The Stopped lifectyle to Deleted lifecycle happens for two reasons: