Back to projects


A server that privately hosts your team's internal Node.js apps

Screenshot of Supertools running in the Safari browser
Year2019Project typePersonal projectMy rolesDesigner, developer, marketerTech stackNode.js, Gitolite, NGINX, PM2, DigitalOcean APILines of code13105Websitesupertools.maxschmitt.meGitHubmaximilianschmitt/supertoolsGitHub (website)maximilianschmitt/supertools-website
The logo is inspired by the Node.js hexagon and the Superman S

Supertools is like a tiny, self-hosted version of Heroku where your apps are only available to your team, organisation or whomever you grant access.

If you’re a developer and need to quickly deploy a little independent tool to your team mates but don’t want to deal with setting up a server or adding authentication code, you can simply deploy it on Supertools by running a single command instead and grant your team mates access.

An explainer video I made for Supertools.

A core challenge for me on this project was getting people to understand what Supertools was for, so I made a few iterations of explainer videos.

This is the last one I made.

Design evolution

It took me a few attempts spread across 2-3 years to finish Supertools in a way that was true to its original vision but manageable as a side project.

Every time that I attempted building Supertools for a few weekends and after work, I learned from my previous attempts and iteratively figured out how the product should work.

Not interested in the history of this revolutionary app? Skip ahead to how the current version works.

Version 1 (2017)

High fidelity design showing a list of apps on the left and the currently selected app running in the main area of the screenHigh fidelity design showing an open widget for creating a new appHigh fidelity design showing an embedded JavaScript editor inside SupertoolsHigh fidelity design showing a settings screen for managing appsHigh fidelity design showing a settings screen for managing usersHigh fidelity design showing a screen for entering a team's Supertools URLHigh fidelity design showing a screen for entering a team's Supertools URL with a dialog to confirm joining the teamHigh fidelity design showing an invitation to join a team with a dialog to accept the inviteHigh fidelity design showing a form to input a team name and Supertools URLHigh fidelity design showing a login formHigh fidelity design showing a signup form

1/11: Viewing / using apps

The general layout of the app was pretty clear to me from day 1. I wanted Supertools to have a sidebar with all the apps you have access to and the currently selected app taking up most of the page.

Overall, I still like the original design. I like the colors with the saturated grays and that the design works well on low-resolution screens.

I started implementing the design and quickly realized that I was spending too much time building all these neat little components and not enough time building the actual functionality for a side project.

Version 2 (2018)

In an effort to try and break out of this design-first mentality, I made myself design the essentials of the app in probably 1 day.

I put the following limitations in place for myself: 1 primary text color, 1 secondary text color, 1 link color, 1 background/border color, 2 or 3 font sizes.

Primitive design showing a list of apps on the left and the currently selected app running in the main area of the screenPrimitive design showing an embedded JavaScript editor inside SupertoolsPrimitive design a settings screen for managing users and your own profile / account settingsPrimitive design showing a login formPrimitive design showing a signup form

1/5: Viewing / using apps

Ugh!! It looks so ugly!! But still usable I would argue – and easy to implement with just a few lines of CSS. The overall layout is still the same as in the original design.

I really wanted to show this design here, even though I'm not proud of it.

The simplicity really made me focus on the core functionality as I was building Supertools this time. I built a very simple but functional in-browser editor. I also made a little process manager that ran the apps in Docker containers and even shut them down after a while if they were idle.

I considered the implementation for this design a successful prototype. Although parts of the system were unreliable and had to be rebuilt. "In a future iteration I'll make it work" I thought...

Current version (2019)

Unlike my previous prototypes, the current version has no in-browser editor for apps. Instead, developers clone a git repository and simply push any changes they've made.

Not only does this allow developers to develop apps locally and use their own code editor, it also means I didn't have to build a code editor for the browser, which seemed like a massive undertaking on its own. 😅

Web app running in Safari showing a list of apps on the left and the currently selected app running in the main area of the screenWeb app running in Safari showing a large textarea to input environment variablesWeb app running in Safari showing a settings screen to configure users and rolesWeb app running in Safari showing a settings screen for app templatesWeb app running in Safari showing general settings like team name, Slack signin, and signup email domainsWeb app running in Safari showing account settingsWeb app running in Safari showing uploaded SSH keys and a form to upload a new oneWeb app running in Safari showing a login formWeb app running in Safari showing a signup form

1/9: Viewing, using and configuring apps

A single screen that allows you to use and configure apps. Depending on the permissions configured for the user you're logged in as, you'll see less options on the right (or none at all).

Getting the design right was really key in making Supertools a reality. While I love polishing the UI and working on little frontend details, I had to find the right balance between aesthetics and being able to focus my development time on the core product.

The current version works almost completely without client-side JavaScript which saved a ton of development time. This is only possible because the design was made with that limitation in mind.

A peak under the hood

The Supertools backend is written for Node.js and runs on an Ubuntu server.

The Node.js backend serves the web-based UI for Supertools and configures the other tools that are part of the system, like Gitolite and PM2.

The codebase for Supertools contains both UI code and all the business logic. Together with the very sparing use of client-side JavaScript, this makes it very fast to develop.

How the pieces fit together

When a user-made app is created on Supertools, a remote git-repository for that app gets created on the Supertools server.

The git repository is placed under control of Gitolite, which is configured by the Node.js backend to only give authorized developers push and pull access.

Each user-made app on the Supertools server runs in its own process. These processes are managed by PM2. When changes to an app are pushed to its repository, a post-receive hook makes sure that dependencies are installed if necessary and that PM2 restarts the app with the updated code.

Oh and apps can also have a build script, so you can even deploy SPAs and such on Supertools. 😎


Supertools makes sure that user-made apps can't be accessed over HTTP directly by never exposing their ports to the public.

To access an app, an authorized user sends their HTTP requests through an access control proxy that runs on the Supertools server. This proxy checks who is trying to access which app and if the user is not authorized, it refuses to forward the user's HTTP requests to the respective app on the Supertools server.

Of course you don't need to know any of this to use apps on Supertools. The ones you have access to simply show up in an iframe inside the web UI. 😜

Marketing website

As with the main product, the marketing website for Supertools went through several iterations.

A simple and friendly landing page for Supertools running in Safari
Version 1: This was a quick and dirty marketing website I put up when I registered the domain for Supertools.
An elaborate landing page for Supertools running in Safari
Version 2: The first "real" marketing website, where I was advertising the hosted version of Supertools.
An simple landing page for Supertools running in Safari
Version 3: The Supertools website as seen today. Keeping it simple and open source. View it online.

As you might be able to tell from some of the clumsy copy, writing the content for the marketing websites is not my biggest strength. It's always a bit of a pain for me but I do aspire to being able to create great marketing materials... it's what sells the product in the end!

Different name and different colors

Here is a website design that never made it live. The working title for Supertools was "cmd" and I was using some 🔥 hot pink colors.

Click the image for the full size.

Docs, docs, docs

For a technical product like Supertools, docs are an important part of showing off how the product works.

I built a little thing into the marketing website that let me write the docs pretty effortlessly with simple markdown files. You can find the current docs on the website.

A project with limitations:
What I learned making Supertools

By setting strict limitations for myself during the final iteration on Supertools, I was able to very quickly implement the project and still create a user experience that is fast, simple and cohesive.

Design that is simple by necessity

I can spend weeks coming up with the perfect design for my side projects. Every individual pixel counts and every element of the UI needs to be carefully designed so that it perfectly supports the user in what he's trying to do.

For Supertools, I had no client-side JS to work with, so I had to design with browser-native form elements. I also refused to use icons and limited myself to a very small palette of colors and font sizes.

All of a sudden the number of possible solutions for a design are drastically reduced, speeding up the process up to taking days instead of weeks.

Avoiding client-side JavaScript

As much as I love creating sophisticated React components, Supertools works with nothing more than browser-native form elements. This speeds up design and development significantly because you don't need to create a custom React component for each individual element in your UI.

The user experience is also great because these browser-native elements are familiar to the user and accessible by default.

A single server, no distributed systems

Because Supertools runs on a single server, the complexity of instracture is extremely low.

It took me 1 or 2 days to create a simple bash script that can reliably provision a Supertools server instance within 3 minutes.

Need help on a project?

I'm available for freelance work.
Send me an email! Or find out more about my services.