Behind the scenes, episode 01: Skalpai, from development to production

Which developer has never pushed a commit just to find out whether their CI would work?

Change a line of configuration. Push. Wait. Find out a variable is missing. Fix it. Push again. Watch the tests pass, then the build fail a few minutes later.

In the end, the code has barely changed.

Everything around it, on the other hand, has taken up part of the day.

My dream was a single system to accompany an application through its whole journey: development, CI and, one day, deployment.

I did not start with deployment.

I started where I lost the most time: the distance between my workstation and CI.

The first problem: finding out too late what does not work

A development environment and a CI are often described twice.

Locally, you start the application, the database, the migrations and the other services it needs.

In CI, you rebuild that same environment with another configuration, other commands and sometimes another way of waiting for services to be ready.

The two descriptions inevitably drift apart.

Something works on the developer's machine but not in CI. A dependency is available locally but missing from the runner. A database already accepts connections here but starts too slowly there.

CI then becomes an environment you can only really test after pushing your code.

change → push → wait → read the error → start again

Skalpai was first born to shorten that loop.

One system for development and CI

The original idea was simple: describe the services and checks in the repository, then run them the same way on the development machine and on a CI node.

sklp dev
sklp run ci

sklp dev starts the application and its dependencies. It knows their start-up order, waits for each service to be truly available and shuts everything down cleanly.

sklp run ci runs the tests and checks in an isolated environment. It can detect which parts of the project changed and run only the relevant steps.

So CI no longer has to start after the push.

It can run locally, while the context of the change is still fresh.

What the remote CI will check later can already be put to the test on the machine where the code is written.

That does not remove every difference between a computer and a remote server.

It removes the ones we created ourselves by describing the same environment twice.

The Space: keeping the same unit of execution

To bring development and CI together, we needed a common building block.

That building block became the Space.

A Space is an isolated environment that brings together an application's services, their network, volumes, dependencies and lifecycle.

It relies on OCI standards and runc, with no Docker daemon. Services get a private network and can find each other by name.

A database called postgres stays postgres. A migration waits for that database to be ready. The application waits for the migration to finish.

These relationships are no longer reinvented for each environment.

The Space does not try to make development look like production. It provides a common unit that can travel through the different stages.

At first, this continuity mainly linked development and CI.

It would gradually become the foundation for the rest.

Using all the power already on our desks

Our computers have become real build machines.

Macs with M-series Apple Silicon chips, in particular, have enough power to run several environments and several checks in parallel.

It became hard to justify leaving all that capacity idle while we waited on a remote machine.

Skalpai turns that local power into testing capacity.

Several changes can be checked. Complete services can be started in isolated environments. A pipeline can run before the code is even sent.

With this approach, I have considerably increased my ability to test what I build every day.

I can try more, catch errors earlier and see the consequences of a change faster.

The gain does not only come from a few minutes saved on a pipeline. It comes from the number of ideas I can actually put to the test in a day.

The development machine is no longer just where code is written.

It also becomes the first place where its whole journey is checked.

Then the applications had to be published

Bringing development and CI together met the first need.

But once the code was checked, the images still had to be produced, scanned for security and pushed to a registry.

That step repeated the same difficulties: new commands, new configuration and new chances to publish something that did not exactly match the validated code.

So Skalpai extended the journey.

develop → check → build → scan → publish

When publishing, it works out which services are really affected by the changes.

Images are built, scanned before they are pushed, then identified by an immutable tag tied to the commit. An image with a blocking vulnerability never reaches the registry.

The system also refuses certain dangerous situations: publishing from the wrong branch, using a Git tree with uncommitted changes, or pushing an image whose origin could not be traced.

The aim is not to multiply rules.

It is to stop problems at the last moment when fixing them is still cheap.

Deployment came next

At first, Skalpai was mainly meant to speed up building applications.

Then those applications multiplied. They started depending on one another. Publishing them was no longer enough: they had to be run, connected and updated without rebuilding their environment by hand every time.

So deployment joined the same system.

Services, their images, resources, volumes, routes and readiness conditions are described in the repository.

Skalpai then brings the real state in line with that expected state.

develop
    ↓
test
    ↓
publish
    ↓
deploy
    ↓
observe

This journey was not all there on day one.

It was built step by step, as the Fabrique's applications needed it.

Today, the same logic follows a change from the development machine all the way to production.

Renting servers, not the whole platform

We rent our servers, like everyone else.

What we want to keep is control of the layer that runs our applications on them.

A fully managed platform can be very quick to adopt. But every application then adds a dependency on its rules, its prices and its limits.

A server stays replaceable.

As long as the system that describes, deploys and observes the applications is ours, changing hosts stays a move rather than a complete rebuild.

This independence does not mean reinventing everything.

Skalpai uses standards such as OCI images and OpenTelemetry. It relies on proven building blocks. What we build ourselves is their continuity and the way they serve our journey.

An alternative to the assembly, not to each tool

Skalpai is not simply an alternative to Docker or Podman.

Those run containers.

Nor is it a copy of GitHub Actions, GitLab CI, Jenkins or CircleCI. Those platforms run pipelines very well.

It does not try to reproduce all the power of Kubernetes, or all the depth of Datadog or Grafana.

Skalpai answers another question:

How many tools do you have to assemble before a developer can simply take their application from code to production?

Its answer is to offer a coherent journey to independent developers and small teams.

Not every possible organisation. Not every scale.

An understandable path for those who build and run their applications themselves.

What Skalpai does today

Skalpai grew with the Fabrique's needs.

Today:

• —it starts development environments;
• —it runs pipelines locally or on CI nodes;
• —it builds only the services affected by a change;
• —it scans images before publishing them;
• —it deploys applications into isolated Spaces;
• —it links machines and services;
• —it collects logs, metrics and traces;
• —it lets you find errors from the interface or the terminal.

Every Fabrique application now relies on this journey.

So Skalpai was not built in theory before them.

It was built with them.

The real time saved

A faster CI saves a few minutes.

A coherent chain above all saves hours of duplication, waiting and diagnosis.

The gain lies in the environment that does not need describing a second time. In the error found before the push. In the vulnerable image stopped before the registry. In the deployment tied to its commit. In the production problem you can find without opening four interfaces.

At first, I simply wanted to stop losing time between development and CI.

Today, Skalpai links development, testing, publishing, deployment and observation.

Skalpai became the Fabrique's foundation not only because it was built first, but because every application now travels the path it opened.

The rest of the series tells what we were able to build once that path was in place.