February 11, 2022
Updated on Dec 11, 2025
Why build your own developer platform?
Introduction
This article is an introduction to the Delivering Vercel-Style Developer Experience with Kubernetes and GitLab series.
Delivering Vercel-Style Developer Experience with Kubernetes and GitLab
- Introduction: Why build your own developer platform?
- Part I: Cluster setup
- Part II: GitLab pipeline and CI/CD configuration
- Part III: Applications and the Dockerfile
- Part IV: Kubernetes manifests
Before diving into technical details, I'd like to give some context. If you want to go straight to the how-to guide, you can skip this introduction and jump to part I.
Starting with WHY
Over the last two years of remote work as a technical leader, I've established a software development life cycle that relies heavily on CI/CD automation.
To make it easier for developers to share their work with other team members, I've set up a workflow that allows any developer to deploy any commit or branch at will.
Sharing development environments can be cumbersome. While tunneling traffic to a developer's machine can do the job, it doesn't fit well in an asynchronous process 1.
A simple solution to this problem is to deploy development environments on managed platforms, as it often requires nearly zero knowledge and configuration.
Accelerating software delivery at the development stage
Vercel, Netlify or Cloudflare Pages are popular managed hosting platforms that automate deployments with a git-centric workflow. It's a simple and easy-to-onboard user experience to solve a complex technical problem.
Beyond simplicity, one feature I like from these platforms is how they keep previous deployments always accessible from a unique URL. I also like how easy it is to promote any deployment to production or rollback to the previous deployment, with just two clicks.
Vercel deployments interface
While it's a very simple way to deploy and rollback applications, these platforms are limited to Javascript frontends and serverless-like functions as backends, also known as the Jamstack architecture.
They are not designed 2 to host popular frameworks such as Rails, Laravel, Django, NestJS, Phoenix, or platforms such as Wordpress or Drupal just to name a few.
Many Git-centric or GitOps oriented platforms have been available long before Jamstack went mainstream. One can either pick a specialized PaaS such as Pantheon for Drupal or Wordpress, Vapor for Laravel, a less specialized PaaS such as platform.sh, or a more general-purpose PaaS like Heroku where you can run Node.js, Ruby, Python, Java, PHP, Go, Scala and Clojure applications.
But the simplicity of these platforms has a cost, and it grows rapidly.
Looking for a better trade-off
Given the current state of the job market, it's often a better option to go with a managed solution than hiring people to run and monitor production servers.
However, managed platforms typically offer only a handful of predefined plans—think "hobbyist, professional, or agency".
This is part of their SaaS business model: they target a specific market with standardized configurations and serve customers who don't want to invest time learning platform operations.
For these customers, overpaying for unused resources is preferable to managing a scalable production setup themselves.
But what about teams running non-critical development environments? How can they get the same simplicity without paying for production-grade features they don't need?
How to cut down on resources waste, and avoid paying for features like high availability infrastructure, high throughput, low latency network?
What I'd like to show here is how to build a simple and cost efficient platform :
| Features | Vercel | Heroku | 👋 Here |
|---|---|---|---|
| One-click deployment From Web UI, GitOps workflow | ✓ | ✓ | ✓ |
| One-click promote to production From Web UI | ✓ | ✓ | ✓ |
| Keep previous deployments accessible Unique https url | ✓ | - | ✓ |
| Run any framework or language Including Rust, Elixir | - | - | ✓ |
What does the solution look like?
Over the course of the series, I'll build a solution with GitLab that consists of three stages:
- Package the application in a Docker image.
- Deploy this image to a Kubernetes cluster and generate a unique URL to access this application instance, such as https://7c77eb36.nodejs.k0s.jxprtn.dev
- Promote the instance to production by pointing a non-prefixed URL to it, such as https://nodejs.k0s.jxprtn.dev
This is what it looks like in GitLab:
A Vercel-like pipeline done with GitLab
Last lines of the deploy job output show a unique URL to access the deployment:
deployment.apps/api configuredingress.networking.k8s.io/api unchangedservice/api unchangedDeployment succeeded.URL: https://7c77eb36.nodejs.k0s.jxprtn.dev/versionCleaning up project directory and file based variablesJob succeeded
Start now and get it right later
Working with development environments is a low-risk strategy that allows a development team to make some mistakes, learn the technology then shape a process that fits their needs.
Recently, Jean Yang posted this article: Building for the 99% Developers, exposing the hard reality a majority of developers faces:
“These are developers who are getting work done outside of the hip companies and frameworks, who often get neglected in conversations about 'what developers want.' There's a huge gap between what 'developer-influencers' are talking about, and the daily reality of most developers.” Jean Yang, founder & CEO of Akita Software
As someone who regularly follows tech news, I couldn't agree more. I've seen firsthand the gap between what's discussed in the tech community and the day-to-day reality of the development teams I've worked with.
I often find myself helping developers who struggle with basic things such as installing local development environments or misconfiguration. So, I'm aware that throwing at them this trendy technology everybody talks about, Kubernetes, doesn't sound like I've understood the problem.
The goal is progress, not perfection
In this series, I'm not describing what Jean Yang calls "an idealized process."
While I've simplified things to focus on key concepts and to improve the narrativity, this setup is part of a real process I've implemented in a development team I've worked with for two years.
It is definitely not perfect, whether because of my ignorance or because I've intentionally left room for improvements.
However, I think it gives a comprehensive starting point to anyone who's trying to make sense of Docker, Kubernetes, CI/CD, GitOps and other trendy topics.
The only fictional piece I've added is instructions to install a Kubernetes cluster with k0s (1. and 2. of part I). I wanted to provide a cheap alternative to managed clusters for people who might want to experiment with this workflow.
The series starts here:
Delivering Vercel-Style Developer Experience with Kubernetes and GitLab, part I: Cluster setup
1 Because the person who asked for access has to sync with a developer, set up a meeting, etc. ↑
2 Back in 2018, when Vercel was still ZEIT, I successfully deployed Wordpress sites on this platform with Docker and Now.sh.Removing such capability while pushing Next.js framework was a clear shift towards the Jamstack emerging market. ↑
4 I tried with a t2.micro with 1 GB of RAM which can be run for free as part of the AWS Free Tier offer and fits the minimal system requirements of k0s for a controller+worker node, but it ended up being pretty unstable. I don't recommend it. ↑
