Dockerizing Playwright/E2E Tests

Author: Zachary Leighton | Cross-posted from Medium

Tired of managing your automation test machines? Do you spend every other week updating Chrome versions, or maintain multiple VMs that seem to always be needing system updates? Are you having problems scaling the number of tests you can run per hour, per day?

If so (and perhaps even if not), this guide is for you!

We’re going to eliminate those problems and allow for scalability, flexibility, and isolation in your testing setup.

How are we going to do that you may ask? We’re going to run your test suite inside Docker containers!


If you haven’t thought about it much, you may wonder why you want to do such a thing.

Well… it all boils down to two things, isolation & scalability.

No, we’re not talking about the 2020’s version of isolation.

We’re talking about isolating your test runs so they can run multiple times, on multiple setups all at the same time.

Maybe you only run a handful of tests today, but in the future you may need to cover dozens of browser & OS combinations fast and at scale.

In this tutorial I’ll attempt to cover the basics of running a typical web application in a Docker container, as well as how to run tests against it in a Docker container using Playwright.

Note that for a true production setup you will want to explore NGINX as a webserver in the container, as well as an orchestration system (like Kubernetes). For a robust CI/CD pipeline also you’d want to run the tests as scripts and have your CI/CD provider run this all in a container with dependencies installed, but more on that later.

You can clone the repo here to have the completed tutorial or you can copy the script blocks as we go along.

The Basics

Creating your app

For this example we’re going to be using the Vue CLI to create our application.

Install the Vue CLI by running the following in your shell:

npm i -g @vue/cli @vue/cli-service-global

Now let’s create the app, here we’ll call it e2e-in-docker-tutorial (but use whatever you like):

vue create e2e-in-docker-tutorial

Follow the on-screen instructions if you want a custom setup, but for this we’ll be using the Default (Vue 3 Preview) option.

After everything finishes installing, let’s make sure it works.

We’ll serve the app locally by running the following:

npm run serve

And open a browser for localhost on the port it chose (http://localhost:8080) and you should see something like this this.

Abba, build me something!

We’ll now write a small sample page that we can use later on to test. It’ll have some basic logic with some interactivity.

For this example we’ll create a dog bone counter, so we can track how many treats Arthur the Cavachon has gotten.

“Is that a dog?” — Arthur

We’ll only have two buttons, “give a bone” and “take a bone” (Schrodinger’s bone is coming in v2).

We’ll also add a message so that he can tell us how he’s feeling. When he is given a bone he will woof in joy, but when you take a bone he will whine in sadness.

And lastly, we’ll keep a counter going so we can track his bone intake (gotta watch the calcium intake you know…).

We’ll write the styles here in BEM with SCSS so we’ll need to add sass and scss-loader to the devDependencies. Note we use version 10 here due to some compatibility issues with the postcss-loader in the Vue CLI.

npm i -D sass sass-loader@^10

The App.vue should look something like this:

  <Arthur />

import Arthur from './components/Arthur.vue'

export default {
  name: 'App',
  components: {

#app {
  font-family: Avenir, Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  color: #2c3e50;
  margin-top: 60px;

And we also have our Arthur.vue component which looks like this:

  <div class="arthur">
    <h1>Arthur's Bone Counter</h1>
    <img src="~@/assets/arthur.jpg" class="arthur__img" />
    <h2 id="dog-message">
      {{ dogMessage }}
    <h3 id="bone-count">
      Current bone count: {{ boneCount }}
      <button class="arthur__method-button" @click="giveBone" id="give-bone">Give a bone</button>
      <button class="arthur__method-button" @click="takeBone" id="take-bone">Take a bone</button>

export default {
  name: 'Arthur',
  data() {
    return {
      boneCount: 0,
      dogMessage: `I'm waiting...`
  methods: {
    giveBone() {
      this.dogMessage = 'Woof!';
    takeBone() {
      if (this.boneCount > 0) {
        this.dogMessage = 'Whine!';
      } else {
        this.dogMessage = `I'm confused!`;

<style lang="scss">
.arthur {
  &__img {
    height: 50vh; // width scales automatically to height when unset
  &__method-button {
    margin: 1rem;
    font-size: 125%;

Once we have that all set up we can run the application and we should see:

Click the “Give a bone” button to give Arthur a bone and he will thank you!

If he doesn’t listen you can also take the bone away, but he’ll be confused if you try to take a bone that isn’t there!

Hosting your built app

In order to host a build we’ll need to add http-server to our devDependencies and create a start script, start by adding http-server:

npm i -D http-server

And add a start script to package.json that will host the dist folder, which is created by running a build, on port 8080:

“start”: “http-server dist -- port 8080”

To test this, run the following commands and then open a browser to http://localhost:8080:

npm run build
npm start

You should see the application running now. Great work! Let’s wrap this all into a Docker container!

I Came, I Saw, I Dockered

Creating a Dockerfile

Now let’s create a Dockerfile that can build the bone counter and serve it up for us.

Create Dockerfile (literally Dockerfile, no extension) in the root of the repo and we’ll base off of the current Alpine Node LTS (14 as of writing this).

We’ll add some code to copy over the files, build the application and run it inside of the Docker container with http-server from our start command.

FROM mhart/alpine-node:14


COPY package.json package-lock.json ./

# If you have native dependencies, you'll need extra tools
# RUN apk add --no-cache make gcc g++ python3

RUN npm ci

COPY . .

RUN npm run build

# Run the npm start command to host the server
CMD ["npm", "start"]

We’ll also add a .dockerignore to make sure we don’t accidentally copy over something we don’t want, such as node_modules, as we’ll install that on the agent.


Going back to the Dockerfile it’s important to note why we copy over the package* files first, which is because of layer caching.

If we change anything in package.json or package-lock.json Docker will know, and will rebuild from that line downward.

If however, you only changed the application files, it will use the cached version of package.json and its install and will only run the layers where we build and after.

This can significantly save some time when you have large installations, or need to rebuild the image multiple times for larger repos.

Let’s now build the image and tag it as arthur. Make sure you’re in the root directory where the Dockerfile is.

docker build . -t arthur

The output should look something like this:

Once it’s built we’ll run the image we just built and we’ll forward port 8080 on the running container to host port 9000 instead of straight through to 8080 on the host.

docker run -p 9000:8080 arthur

Notice we see in the log that it’s running on port 8080, but this is from inside the container. To view the site we need to go to our host machine on port 9000 that we set using the -p 9000:8080 flag.

Navigate to http://localhost:9000 and you should see the app:

Congratulations! You are now running a web application inside of a Docker container! Grab a celebratory coffee or beer you want before continuing on, I’ll just wait here watching cat videos on Youtube.

Thou Shalt Test Your App

Writing a Playwright test

For the next part, we’ll cover adding Playwright and jest to the project, and we’ll run some tests against the running application. We’ll use jest-playwright which should come with a lot of boilerplate type code to configure Jest and also run the server while testing.

Playwright is a library from Microsoft, with an API almost 1 to 1 with Puppeteer that can run a browser via a standard javascript API.

The big difference is that Puppeteer is limited to chromium-based browsers, but Playwright includes a special WebKit browser runtime which can help cover browser compatibility with Safari.

For your own needs you may want to use Selenium,, Puppeteer, or something else altogether. There are many great automation and end-to-end testing tools in the JavaScript ecosystem so don’t be afraid to try something else out!

So going back to our tutorial, let’s start by adding the devDependencies we need, which are Jest, the preset for Playwright, Playwright itself, and a nice expect library to help us assert conditions.

npm install -D jest jest-playwright-preset playwright expect-playwright

We’ll create a jest.e2e.config.js file at the root of our project and specify the preset along with a testMatch property that will only run the e2e tests. We’ll also set up the expect-playwright assertions here as well.

module.exports = {
  preset: 'jest-playwright-preset',
  setupFilesAfterEnv: ['expect-playwright'],
  testMatch: ['**/*.e2e.js']

Please note that this separation by naming doesn’t matter much for this demo project. However, in a real project you’d also have unit tests (you *DO* have unit tests with 100% coverage don’t you…) and you’d want to run the suites separately for performance and other reasons.

We’ll also add a configuration file for jest-playwright so we can run the server before we run the tests. Create a jest-playwright.config.js with the following content.

// jest-playwright.config.js

module.exports = {
    browsers: ['chromium', 'webkit', 'firefox'],
    serverOptions: {
        command: 'npm run start',
        port: 8080,
        usedPortAction: 'kill', // kill any process using port 8080
        waitOnScheme: {
            delay: 1000, // wait 1 second for tcp connect 

This configuration file will also automatically start the server for us when we run the e2e test suite, awesome dude!

Writing the tests

Now let’s go ahead and write a quick test scenario, we’ll open up the site and test a few actions and assert they do what we expect (arrange, act, assert!).

Go ahead and create arthur.e2e.js in the __tests__/e2e/ directory (create the directory if not present).

The tests will look like the following:

describe('arthur', () => {
    beforeEach(async () => {
        await page.goto('http://localhost:8080/')

    test('should show the page with buttons and initial state', async () => {
        await expect(page).toHaveText("#dog-message", "I'm waiting...");
        await expect(page).toHaveText("#bone-count", "Current bone count: 0");

    test('should count up and woof when a bone is given', async () => {
        await expect(page).toHaveText("#dog-message", "Woof!");
        await expect(page).toHaveText("#bone-count", "Current bone count: 1");

    test('should count down and whine when a bone is taken', async () => {
        // first give 2 bones so we have bones to take!
        await expect(page).toHaveText("#dog-message", "Woof!");
        await expect(page).toHaveText("#bone-count", "Current bone count: 2");

        await expect(page).toHaveText("#dog-message", "Whine!");
        await expect(page).toHaveText("#bone-count", "Current bone count: 1");


    test('should be confused when a bone is taken and the count is zero', async () => {
        // check it's 0 first
        await expect(page).toHaveText("#dog-message", "I'm waiting...");
        await expect(page).toHaveText("#bone-count", "Current bone count: 0");
        await expect(page).toHaveText("#dog-message", "I'm confused!");
        await expect(page).toHaveText("#bone-count", "Current bone count: 0");

We won’t go into the specifics of the syntax of Playwright in this article, but you should have a basic idea of what the tests above are doing.

If it’s not so clear you can check out the Playwright docs, or try to step through the tests with a debugger.

You might also get some eslint errors in the above file if you are following along and have eslint on VS Code enabled.

You can add eslint-plugin-jest-playwright and use the extends on the recommended setup to lint properly in the e2e directory.

First install the devDependencies eslint-plugin-jest-playwright:

npm i -D eslint-plugin-jest-playwright

Then create an .eslintrc.js file in __tests__/e2e with the following:

module.exports = {
    extends: [

Goodbye red squiggles!

Run tests run!

Now that the tests are set up properly, we’ll go ahead and add a script to run them from the package.json.

Add the test:e2e script as follows:

“test:e2e”: “jest — config jest.e2e.config.js”

This will tell jest to use the e2e config instead of the default for unit tests (jest.config.js).

Now go ahead and run the tests, keep up the great work!

Note that you may need to set up some libraries if you don’t have the right system dependencies. For that please consult the Playwright documentation directly, or just skip ahead to the Docker section which will have everything you need in the container.

Running it in a Docker container

Now we’ll put it all together and run the e2e tests inside a Docker container that’s got all the dependencies we need, which will let us scale easily and also run against a matrix (we don’t touch on this in this article but maybe in a part 2).

Create a Dockerfile.e2e like so:

# Prebuilt MS image


COPY package.json package-lock.json ./

RUN npm ci

COPY . .

RUN npm run build

# Run the npm run test:e2e command to host the server and run the e2e tests
CMD ["npm", "run", "test:e2e"]

Note that the CMD here is set to run the e2e tests. This is because we want to run the tests as the starting command for the container, not as part of the build process for the container. This isn’t how you’d run with a CI provider necessarily so YMMV.

Go ahead and run the docker build for the container and specify the different tag and Dockerfile:

docker build . -f Dockerfile.e2e -t arthur-e2e

In this demo we build the container with the tests baked in, but in theory you exclude the tests from the COPY command and could mount a volume of the tests so you wouldn’t need to rebuild between test changes.

We can run the container and see the tests with the following command (the --rm flag will remove the container at the end of the test so we don’t leave containers hanging):

docker run --rm arthur-e2e

You should see output like the following:

Great job! You just ran e2e tests in WebKit, Chromium and FireFox in a Docker Container!

If you enjoyed this tutorial and you’d like to participate in an amazing startup that’s looking for great people, head over to Tipalti Careers!

If you’d like to comment, or add some feedback also feel free, we’re always looking to improve!

The Leap from .NET to Linux – Using PM2 with sensitive configurations in production

Authors: Shmulik Biton, Ron Sevet

It’s not very often in the career of a programmer that one has the privilege to deploy a brand new application to production. We were lucky to be in that position. This was even more special since this was a completely new technology stack that we were introducing here at Tipalti. Our entire server-side stack is based on .NET and the various Microsoft products that go along with it. We have an extensive experience with .NET’s best practices, tools, how to run our applications and how to secure them.

This wasn’t the case here. Our new application is written in Node.js and we wanted to run it on Linux for better performance. This meant we had to find how to apply the practices and capabilities from our .NET stack on the Linux stack.

We had two major tasks, the first was to find a capable solution for running our node application. We searched around and found PM2. PM2 is a very comprehensive process manager with many useful features. It’s popular, well maintained and looked very promising.

Securing Configurations

After setting up PM2, we needed a way to secure our sensitive configuration keys like DB credentials and alike. In .NET, you can simply use the Windows Protected Configuration API for a seamless experience. Your web.config is encrypted using the user’s credentials and .NET handles it without too much fuss. You don’t need to store any encryption keys next to the config so it’s a pretty good solution.

In Linux, there isn’t something similar, and after some research, we found a best practice that seemed reasonable to us: storing sensitive configurations as environment variables. The reasoning here is that accessing this file requires either root access or the ability to run code on the machine, which in that point there is not much you can do to keep those variables a secret.

At first, all went well. PM2 performed as expected, and using the environment variables was an easy solution.

The issues started after we had duplicated our server and had to change some of those environment variables. We started getting weird errors that we did not see before. We found out that we were still using the old configurations. Using the `pm2 reload` command did not have any effect. Nor the `restart` command or even restarting the server itself. This was very baffling. It turns out that PM2 was the culprit here. One of PM2’s features forces you to explicitly reload environment variables in order to get the updated values. The flag to use is `–update-env`. This seemed to fix the issues we thought the problems are behind us.

We were wrong. After some time has passed another config change was required and this time the flag did not work. Nothing seemed to work. Rebooting the server did not have any effect either. We figured there must be some sort of a cache PM2 was using to store the application state. This was indeed the case.

We used the command `pm2 save` which creates a dump file on ~./pm2/. When the app started/reloaded/restarted it used that dump file to continue where it left off. This behavior was not desired for two reasons: First, it stopped us from updating our configuration. Secondly, it stored sensitive configurations in the home directory of the user running our app. This can potentially expose us to file traversal attack vectors.

Solving the Issue

We solved it by deleting the dump file and stopped using the `pm2 save` command. We also changed the default startup script PM2 creates when you call `pm2 startup`.

This is our final startup script:

Description=PM2 process manager


ExecStart=/usr/lib/node_modules/pm2/bin/pm2 start /home/integration/.pm2/ecosystem.config.js
ExecStartPost=/usr/lib/node_modules/pm2/bin/pm2 reload /home/integration/.pm2/ecosystem.config.js
ExecReload=/usr/lib/node_modules/pm2/bin/pm2 reload /home/integration/.pm2/ecosystem.config.js --u
ExecStop=/usr/lib/node_modules/pm2/bin/pm2 kill


Note that you need to specify in the startup script the environment file explicitly, otherwise, it won’t load it, and since we are already specifying the file path, we decided to use a dedicated file with root permissions instead of /etc/environment. This would prevent a general process to have access to our configuration.

A quick note on key store solutions: We thought it would add another layer of complexity without adding much security. If someone got root access to the machine they could get the configuration no matter what we do. This is why we decided not to go that route.

In summary

If you want to run a Node.js application under Linux using PM2, these are the steps that we found worked best:

  1. Put sensitive configuration variables in a root accessible file
  2. Do not use the `pm2 save` command
  3. Change the startup script as shown above
  4. Reload your application after changing the configuration using
    `pm2 reload <your config file name> –update-env`