News from the factory | MicroSaaS Toolkit

The cell, our unit of infrastructure: built by one command in 1.7 minutes

2026-10-23T00:00:00Z

A factory that keeps adding products needs a unit of infrastructure that keeps its shape as it grows. Ours is the cell.

What a cell is

By design, a cell is a self-contained unit, today one server, with everything a product needs to serve its users: an edge holding the TLS certificates and names of the cell's products, a nightly backup and monitoring, all behind a firewall of its own. Each product environment is placed in exactly one cell, and its name points at that cell.

At run time, cells share nothing: no network, no edge, no database. Outside them stay the parts that serve no requests, such as CI and the image registries.

On 22 October the cell replaced our earlier plan, one central edge for every name of every product. With products on several servers, all would fail with the server holding that edge, and reaching the rest would need a private network and service discovery kept by hand. With cells, a failure stays in its cell, and the factory grows by adding cells, not by enlarging a server.

By design, moving a product is three steps: the same image on the new cell, its data, and its name pointed at the new cell. What a product brings, images built in CI, configuration from its environment and a health check the deploy waits for, is what an orchestrator such as Kubernetes also asks for, so that choice stays open.

The first cell built by script

A unit of infrastructure is worth what the next one costs. bin/cell.sh build turns a fresh Ubuntu server into a cell, each part by its own repository's script: host settings, firewall, edge, monitoring and backup.

On 23 October it ran on a throwaway server in another data centre: half a minute for the server, 1.7 minutes for the cell. Then we deployed a live product's production release on it unchanged and restored its two databases from that night's dumps. The whole run took 3.8 minutes and all 13 checks passed, from row counts against the dumps to the product's site and API answering through the new edge. Its name was not pointed at the copy, on purpose, so the copy received no customer requests; then the server was deleted.

The next cell starts from the same command, and the first one's time is on record.

The site that announced our design-system kit now builds on it

2026-10-21T00:00:00Z

Since 13 October Reputo and Leadgener have pinned one design-system kit, and this site announced it the same day. The site itself did not use the kit: it kept its own colour values for both themes, IBM Plex Sans where the kit sets Inter, its own buttons and focus outline.

One package, two written exceptions

On 21 October 2026 the site moved onto the kit's npm package, pinned at 1.1.0. In the light theme its surfaces, text and borders now take the kit's roles, and its buttons, heading weights, text typeface and the focus ring on its controls are the kit's. The toolkit's blue lives in brand.css: the twelve colour roles of the kit's brand contract, checked by the kit's assertBrand in the site's tests, as in Reputo and Leadgener. A light blue action colour fails that test at 1.80 : 1, below the minimum of 4.5 : 1.

Pieces the kit has no counterpart for, such as the factory floor, stay the site's own; for two of them, the decision to adopt the kit writes down why they stay out of it. The kit has no dark theme and no product needs one, so under our harvest rule it does not go into the kit; 13 tests keep the site's dark text and button colours at 4.5 : 1 or more. Nor does the kit have a filter chip, so the toggles that filter the factory floor and the news stay a site control on kit tokens until a product needs one.

Tailwind inside the kit's layers

The kit declares seven cascade layers; the last, product, is for a page's own CSS. This site's Tailwind emits CSS outside any layer, and such CSS beats every layer whatever its specificity: Tailwind's reset would have undone the kit's buttons. So the build runs Tailwind twice, putting its reset into the kit's reset layer and everything else into product. Three checks can then stop the build: the layers must appear in the kit's order, no rule may stand outside a layer except @font-face, and every local url() must name a file the build wrote. We broke each on purpose; each stopped the build with its own message.

The Docker image build on main runs the same build, and the deploy waits for that image: the first pipeline installed the kit, built the image and finished the deploy 83 seconds after the change was merged.

The kit's CSS thus works here without any of its React components: two passes put Tailwind's output inside the kit's layers, and the build fails when a rule leaves them or their order changes.

A layer cache for image builds, and the canary that caught its first release

2026-10-20T00:00:00Z

GitLab's shared runners start every job with an empty Docker. An image build from the delivery kit therefore restored its NuGet packages and compiled the API from nothing on every run, including runs where no backend file had changed.

The cache lives in the registry

Delivery kit 1.4.0, released on 20 October 2026, gives the image-build component an input cache with two values: none, the default, and registry. With registry the build runs with buildx on the docker-container driver and reads its layers from <image>:buildcache in the project's container registry. Only the default branch writes them back. A merge request build reads the cache and pushes nothing, so it cannot replace the layers that main relies on. A product that does not set the input sees no change.

The cache asks one thing of a Dockerfile: restored packages must stay in an image layer. A RUN --mount=type=cache directory is never exported to the registry, so a restore layer taken from the cache would leave the next step without its packages. Probe, the product we keep to take every kit release first, dropped its NuGet cache mounts for that reason.

Caught on a real runner

Version 1.4.0 passed its tests on a workstation and failed on Probe's first build five minutes after release. The kit's jobs talk to Docker over TLS, and docker buildx create refuses TLS settings taken from the environment. No other product had pinned it. Version 1.4.1, released 14 minutes after 1.4.0, creates the builder on a Docker context made from the same settings.

Until then the kit's own pipeline checked that image-build renders, but never ran its script. A new job, delivery:image-build-test, runs that script on a TLS Docker-in-Docker, as in a product's pipeline, against a registry started inside it. It checks that the default branch writes the cache, that a new builder reads it, that another branch reads it and pushes nothing, and that a build without a cache still works. Against the 1.4.0 template it fails 7 of its 10 checks.

On Probe's main, the first build of the API image took 91 seconds and wrote the cache. A rerun of the same commit, the best case, took 33 seconds, with the restore and publish steps served from the registry. In Probe's Dockerfile the restore layer depends only on the project and build settings files, so a commit that changes only code should still reuse it.

To use it, pin 1.4.1, set cache: registry on the images with a slow restore, keep the buildcache tag out of the registry's cleanup policy, and remove package cache mounts from the Dockerfile first.

Security checks a product gets from the delivery kit

2026-10-19T00:00:00Z

On 19 October 2026 we moved three checks from our products' own pipelines into the delivery kit: a secret scan, a NuGet dependency check, and a check of the addresses that must stay closed after a deploy. A product started from Reputo's pipeline has all three from its first pipeline. The kit's frontend gate already ran npm audit.

Three checks in the kit

Delivery kit 1.1.0 adds a component, secret-scan, that runs gitleaks over the commits a pipeline brings: the merge request's, or a branch's since its previous head. It needs no other job, so it never waits for the build or holds it back. The dotnet-test component now runs dotnet list package --vulnerable --include-transitive right after its restore and fails on a high or critical advisory. It reuses that restore, so the scan adds seconds, not a second restore. Turning it off takes an input, vulnerability_scan: false, which the kit's documentation allows only with a dated reason in the product's pipeline.

Version 1.2.0, released the same day, gives the deploy component an input closed_urls: addresses that must answer 401, 403 or 404 once the deploy is done. A 2xx or 3xx answer fails the check at once, without retries.

Adopted on release day

Reputo and Leadgener moved to 1.1.0 that afternoon. Both pipelines ran the secret scan and the NuGet scan, and neither scan found anything.

That evening, on delivery kit 1.3.0, both products set closed_urls for three addresses: the identity server's admin console, its master realm and the Swagger page. Every deploy now proves that they stay closed: Reputo's dev deploy at 17:43 UTC and Leadgener's at 17:47 UTC logged all three as closed (404).

The check lives in the kit and the rules do not, by design: what closes an address differs by product (a gateway rule, the API's own settings), while whether it is closed is the same question everywhere. A product started from Reputo's pipeline inherits the three addresses, so its first deploy fails if anything that closes them is missing.

Toolkit 1.0.3 reached all three live products within an hour of release

2026-10-19T00:00:00Z

Every product pins the toolkit in one line, and a release does nothing until a product changes the version in that line. Until 19 October 2026 that was manual: a release meant editing the pin in each product and finding out from each product's pipeline whether it still built.

Two scripts, before and after the release

factory/check_consumers.py takes every active product in the factory registry that pins the toolkit and builds it against a toolkit checkout instead of the published packages, before anything is released. factory/propose_upgrade.py then opens the upgrade merge request in every product that pins an older version. It changes the pin and nothing else, and each merge request's description carries the changelog sections of every version newer than the product's pin, so whoever merges sees what the product must act on.

Toolkit 1.0.3 removed the one place where a package referenced one in a higher layer: Tenancy.Runtime no longer depends on Organizations.Api. It also pins the Stripe library to an exact version. Before release, check_consumers.py built all five products against the change.

The timeline on 19 October

The 19 packages of 1.0.3 were published at 16:00 UTC. The first real run of propose_upgrade.py pushed the branches to Gostly, MojRazpis and SnapMind but opened no merge requests: it took the source project from the directory it ran in. The fix creates them through the API by project name and lets a rerun finish what a failed run started; the rerun opened the three at 16:04. Reputo and Leadgener took the release in merge requests of their own, together with the delivery kit's new security scans. All five were merged by 16:09.

Production deploys are still a button the owner presses. MojRazpis and SnapMind ran 1.0.3 in production from 16:39, and Gostly, whose changes go to its development branch first, from 16:54. From publishing to the last production deploy took 54 minutes, and the factory registry records the release with the date it reached every live product.

Nothing made the five move together: each merge request ran its own pipeline, and a product that leaves its merge request open stays on its old pin. Version 1.0.3 was not a security release. A security fix will take the same path: built against every product first, then proposed to each of them.

The delivery kit: one pipeline and deploy instead of two hand-kept copies

2026-10-15T00:00:00Z

Reputo and Leadgener, our two products in development, were built, tested and deployed with copies of one pipeline and one set of deploy scripts, kept by hand. By 15 October the copies had drifted. The two deploy scripts (116 and 111 lines) differed in 47 lines, and the two scripts that start the stack on the server (64 and 82 lines) in 66. Part of that is product names and comments; part is behaviour: the two products took their backups in two different ways. A fix in one copy did not reach the other, and Leadgener's first pipeline had already lost a build flag in the copying.

Six components and an ops image

On 15 October 2026 we released delivery kit 1.0.0. It does for build and deploy what the NuGet packages did for the backend and the Keycloak kit for identity: six GitLab CI/CD components (backend tests, a frontend gate, sharded frontend tests, image builds, the deploy and a restore test) and an ops image that runs the deploy and the restore test. A product includes every component at @delivery-v1.0.0. There is no latest, and the changelog flags each change by what it touches: [contract], [behaviour] or [pipeline].

Version 1.0 is a faithful port of the two pipelines; the design lists each change in behaviour with its reason. The backup follows Leadgener's design: a dump with checksums and the row count of every table in the application database. One thing changes: the kit takes those counts inside the dump's snapshot. A product keeps its inputs, its compose files and hooks for what only it needs, such as provisioning its Keycloak realm.

Proven on both products the same day

Before the release, Reputo adopted the kit at a pinned toolkit commit. A report compared its merged pipeline before and after, job by job, and the merge request explains every difference. Test totals were unchanged: 2,298 backend and 2,591 frontend tests. On main, the kit's deploy backed up both databases, provisioned Keycloak through Reputo's own hook and passed the health gate, and the restore test restored that backup into a throwaway container: 33 tables, every row count equal.

Reputo then pinned 1.0.0, and Leadgener moved the same evening. Its first restore test on the kit checked 25 tables and, through its own hook, that the 3,391 files its database points to are present with matching checksums. Both products deleted their deploy scripts, and Reputo's .gitlab-ci.yml went from 290 lines to 172.

A change to the shared jobs, the deploy, the backup or the restore test is now made once, in the kit; what only one product needs stays in that product's inputs and hooks.

Design-system kit 1.1.0: a new look, released once, pinned twice

2026-10-14T00:00:00Z

The design-system kit 1.0 kept the look our products already had: Arial, square corners, 2 px borders on buttons and inputs, uppercase labels on tags and KPI tiles, a dark footer. We wanted them to look like current SaaS products. In two copies of the design system that would have been the same restyle twice; since the shared kit of 13 October, it is one release.

A new surface on the same components

On 14 October 2026 we released design-system kit 1.1.0. Inter replaces Arial and ships inside the package, never from a font CDN. Corners get small radii: 3 px for chips, 4 for controls, 6 for cards. Borders on buttons and inputs drop to 1 px, cards get a soft shadow, and the footer is a light panel.

Markup and page structure stay as they were, and no component prop was removed or renamed. The look is core: a product still sets only its twelve colour roles, because roles for type, radius or depth would let the products drift apart again. The kit's guarantees did not change: the focus ring, 44 px touch targets, contrast, tones marked by shape as well as colour.

Between 1.0.1 and 1.1.0 the kit's stylesheets changed in 33 files, 466 lines added and 146 removed, and every one of its 384 baseline captures changed.

What the products changed

Reputo and Leadgener each pin the kit in one line of their frontend's package.json; the frontend also builds their login pages. Reputo moved that pin from 1.0.0 to 1.1.0 an hour after the kit's merge request merged, so it took the 1.0.1 patch as well. In its app code, the frontend's src, three files changed: its check, incident and DNS-record cards now read the kit's new card radius and elevation tokens, 20 lines added and 7 removed.

Leadgener pinned 1.1.0 two hours later. In its app code, its own stylesheets now read the kit's font-weight tokens instead of a literal 700. One screen needed a code change: its opportunities table has nine columns, so it takes the new stackBelow="wide" option: below 1160 px of its own width, it shows each row as a list of labelled fields, with the date and the time as separate parts.

On the toolkit, a new look is a minor version: you pin it, run the checks its changelog lists for the release, and re-check your screens; a table too wide for its box takes one prop.

The factory registry: what each product pins, checked against its repository

2026-10-13T00:00:00Z

A product pins our kits in its own repository: the toolkit version in Directory.Build.props, the Keycloak kit in a Dockerfile, the design-system kit in frontend/package.json. Until 11 October nothing recorded which product used which version, or whether a shared change had reached production.

One declaration, checked

On 11 October 2026 we added factory/products.toml, the factory's product registry. For each product it declares the stage, the owner, the integration and production branches, the versions under kits.nuget, kits.keycloak and kits.design_system, and, for a product in production, the deploy job and the commit that production runs.

factory/check_registry.py compares that declaration with each product's repository at origin/<branch>, never the working tree, so unpushed work does not count. --fetch fetches every checkout first; --gitlab asks GitLab for the commit of the newest successful deploy job. Each finding is one line with a verdict. DRIFT means the registry and the repository disagree, and either may be wrong. FAIL marks an operational risk, such as a vendored toolkit, a target framework within 90 days of its end of support, or a design-system pin other than the registry's. Any FAIL or DRIFT makes the script exit with code 1.

What it found on 13 October

The registry's header asks that each change to it go in the same merge request as the change that makes it true. A kit pin cannot follow that rule: the pin changes in the product's repository, the registry in ours. On 12 October the registry recorded Keycloak kit 1.0.1 for Reputo and Leadgener. That evening both moved to 2.0.0. Two merge requests changed the registry the next day; neither touched those lines.

A run on 13 October reported the drift among its other findings:

DRIFT  reputo       main: Keycloak kit pins ['2.0.0'], registry says 1.0.1
DRIFT  leadgener    main: Keycloak kit pins ['2.0.0'], registry says 1.0.1

The design-system pins, added to the registry a few hours earlier, matched in both products. The fix is one line per product in products.toml.

For a team building on the toolkit, the registry checks a rule we set for our own upgrades: an upgrade is done when production runs it, not when its merge request merges. With --gitlab, for a product in production, the check reads the toolkit version from the commit GitLab last deployed and warns when it is not the version the registry declares. The registry records, for each product, the kit versions its integration branch pins, and one run of the check shows where that record and the repository disagree.

The Keycloak kit: one pinned image, a theme per product

2026-10-13T00:00:00Z

Each product signs users in through its own Keycloak, and the toolkit's API packages trust what that Keycloak writes into a token. Reputo and Leadgener used to build from quay.io/keycloak/keycloak:26.0, a tag that moves with every patch, so two builds of one commit could run different Keycloak versions.

What the kit holds, and what it leaves out

On 11 October 2026 we decided that the Keycloak kit would be one base image carrying only what must be the same in every product's Keycloak: Keycloak pinned by digest, jq pinned by checksum, 32 of Keycloak's login messages in Slovenian, and two commands that run inside the container through docker exec.

setup provisions what the API reads from a token: the audience, realm roles flattened into a roles claim that ASP.NET reads, and a declared organization_id attribute, which Keycloak 26 would otherwise drop without an error.
require-terms makes accepting the terms of use a required action for every user, so Keycloak issues no token until the user accepts them. Only the time of acceptance is stored.

The kit holds no product defaults: realm name, client IDs and origins live in a wrapper in the product, and setup stops before any change, naming each one that is missing. It holds no login theme either, because a theme carries its product's brand on top of the shared design system. The product's Dockerfile builds the theme JAR in an earlier stage, then:

FROM <kit image>:<X.Y.Z>@sha256:<digest>
COPY --from=theme /app/keycloak-theme/dist_keycloak/reputo-keycloak-theme.jar /opt/keycloak/providers/
RUN /opt/keycloak/bin/kc.sh build --db=postgres --health-enabled=true

Tested, pinned, upgraded by choice

Every merge request that changes the kit runs six test suites against the built image. One checks each Slovenian message against the Keycloak inside the image: a key it knows, the same placeholders.

There is no latest tag, and a published version is never overwritten. On 13 October Reputo and Leadgener were pinned to the same version and digest. The changelog flags what a version asks of a product: [keycloak] (back up the database first), [contract] (a command, variable or path changed) or [behaviour] (the realm comes out different). Any Keycloak version change is a major kit version, because Keycloak migrates its database one way. By 13 October the kit had five versions; how the kit was harvested is told in the post on the harvest rule.

For a team building on the toolkit, the identity rules arrive with the image: tokens carry what the API checks, and no token is issued before the terms are accepted. Your login pages and your realm's values stay yours.

One design system, a brand layer per product

2026-10-13T00:00:00Z

Our design system started in Reputo: CSS tokens, React components, lint rules that keep screens from setting their own styles, and a catalogue. On 8 October Leadgener copied its 209 files and changed the palette. Four days later, 26 files present in both copies differed and 14 existed in only one. Some differences were Leadgener's own components; one was a fix that stayed where it was made, a narrower tab padding that fits three tabs on one row of a 375 px wide phone screen. Reputo's tabs still wrapped.

The core is shared, the brand is not

Under our harvest rule, look and feel were copied on purpose. On 12 October we made the design system the exception. Its core sets the quality of the interface and must not diverge: the focus ring, 44 px touch targets, contrast, tones marked by shape as well as colour, and the type and spacing scales. It became the design-system kit, an npm package released like our other kits, with a dated changelog section and a protected tag.

A product keeps a brand layer: brand.css with exactly twelve colour roles, its mark, and its own components under its own prefix. Its tests call assertBrand, which fails when a role is missing, when the file sets any other kit property, when a role falls below its WCAG 2.1 contrast minimum, or when an action colour could pass for a success, warning or danger state. The app shell, the login theme and the landing page stay copies, but in Reputo and Leadgener each imports the kit's stylesheet, then brand.css.

Compared, then released

Kit 1.0.0 is a faithful port of Leadgener's copy. We captured every catalogue entry at 375, 768 and 1366 px and compared the kit with both products pixel for pixel. Apart from entries listed as different by construction, the only rendering change is the tab fix, which now reaches Reputo. The kit's 384 captures became its baseline for every merge request that changes it.

Before it publishes, the release job requires a rehearsed candidate of the same code to verify in the registry, and runs the suite again on the merge commit: 615 tests for 1.0.0. Reputo and Leadgener adopted the candidate, compared their catalogue and all nine login theme pages with what they rendered before, and pinned 1.0.0 the same day.

If you build on the toolkit, your product's colours are one file the kit checks: a palette that fails contrast fails your brand test before it reaches a screen. A fix like the tab padding is made once, in the kit, not in each copy.

Keycloak 26.0 → 26.8: what bit us, and where the kit keeps it

2026-10-12T00:00:00Z

Keycloak kit 1.x was pinned to 26.0.8, eight minor versions behind 26.8, and received none of their fixes. Had each product upgraded on its own, each would have met the same surprises in its own pipeline.

One upgrade, in the kit

On 12 October 2026 we released Keycloak kit 2.0.0 on Keycloak 26.8.0. In the kit's Dockerfile that is two lines: the FROM with its digest, and a LABEL repeating the version, which the structure suite now checks against that FROM. What bit us went into a test or the changelog.

A test that read nothing. Keycloak 26.8 ships keycloak-themes-vendor-*.jar beside the themes JAR. Our messages suite looked for keycloak-themes-*.jar, matched both and copied neither, so all 32 Slovenian keys looked unknown. The translation was fine; the test was not. It now accepts exactly one JAR, and fails on its own when it reads fewer than 100 English keys.
New realm defaults. Compared with 1.x, the realm the kit provisions differs only in Keycloak's own defaults for a new realm, as the diff of the golden realm exports shows. Among them: three new required actions, WebAuthn passwordless requiring a resident key and user verification, no X-XSS-Protection header, and a realm-management client that is read-only in the admin API. The provisioning did not change, and accepting the terms of use is still the default required action. An existing realm is migrated by Keycloak, not re-created, so its values can differ.
Login themes. Since 26.7, templates run with FreeMarker 2.3.32 defaults, and since 26.5, no message renders HTML except termsText, which kit 2.1.0 can set to link the terms of use and the privacy policy. Before the release we built Reputo's theme on the new image: the login and terms pages rendered without template errors.

The changelog entry lists the rest: PostgreSQL 14 or later, single-use required-action links, the refusal of redirect URIs that carry state or code, and the upgrade steps from kit 1.x.

Reputo and Leadgener moved the same day, each in a merge request that changes only the kit pin and its comment, and both dev environments were deployed on 26.8.0 that evening.

For a team on the Keycloak kit, a Keycloak upgrade arrives as a kit version that has already passed these tests, its changes written in the changelog. Your part is a backup of the Keycloak database before the first start of the new version, the pin, a build of your login theme on the new image if you have one, and one look at the login, registration and terms pages on dev.

We shipped Keycloak kit 1.0.0 broken

2026-10-12T00:00:00Z

On 11 October 2026 the Keycloak kit's CI ran all its test suites against the 1.0.0 commit and reported FAILS=0. The release job then pushed the image. Fourteen minutes later, Reputo's dev deploy stopped at provisioning:

bash: /opt/microsaas/keycloak/setup: Permission denied

What was broken, and why the tests passed

The directory /opt/microsaas/keycloak had mode 644. Without the execute bit, Keycloak's user, uid 1000, could not enter it, so neither setup nor require-terms could run. The Dockerfile never created that directory itself: a COPY --chmod=644 of the Slovenian messages file created it as a parent, and the mode of such a parent is up to the BuildKit that runs the build.

Two BuildKits built 1.0.0. The test job ran docker build, with Docker's built-in BuildKit, and got 755. The release job ran buildx with the moby/buildkit image it pulls by default, unpinned and at that time v0.33.1, and got 644. One commit, one Dockerfile, two images. Every suite passed on the image we did not ship, and nothing tested the one we did.

Reputo's dev environment kept serving, because its realm lives in the database. Only Reputo and Leadgener had pinned 1.0.0, and neither runs in production yet.

Test the artifact you ship

The rule we adopted: test the artifact you ship, built by the builder that ships it. The main fix was merged that evening, and 1.0.1 was published the next morning. What changed in CI:

One BuildKit, pinned by version and digest in release/builder.sh, builds both the image the tests run on and the image that is pushed. The Dockerfile frontend is pinned by digest too.
The Dockerfile creates every kit directory with mode 755 before any file is copied in, so the modes no longer depend on the builder.
The structure suite checks, as uid 1000, that every directory can be entered and every file read or run.
After the push, the release job pulls what the registry serves and tests that. Since 1.0.2 it compares every path under /opt/microsaas, with its mode and owner, in both the amd64 and arm64 images against a fixed list, and creates the version's tag only after both images pass.

For a team building on the toolkit, every Keycloak kit version since 1.0.2 was tested on an image from the builder that pushed it, then checked again as the image you pull, on both platforms. You take its digest from its release notes, and a version that fails the check after its push gets neither notes nor tag: its changelog section is marked defective, and the fix ships as the next patch.

A landing page with no third parties before consent

2026-10-12T00:00:00Z

Until 12 October, before a visitor read a word, microsaaskit.dev fetched IBM Plex from Google Fonts, Font Awesome from a CDN, Tailwind as a script that compiled the styles in the browser, and Google Analytics. We rebuilt the last version before the change and loaded its home page in headless Chrome: on a first visit it made 11 requests to five other hosts without asking, not counting the Google Analytics request, which our run blocked.

What we changed

Google Analytics now loads only after the visitor chooses “Allow analytics”. “Decline” sits next to it in the same size and style, and “Cookie settings” in the footer reopens the banner. The fonts come from the site: two IBM Plex families in the latin and latin-ext subsets, 14 files the build copies from Fontsource. Lucide outline icons and Simple Icons brand marks replaced Font Awesome, inlined as one SVG sprite per page; the build fails if a page uses an icon the sprite lacks. Tailwind is compiled at build time.

The same day, the page became two static pages, English at / and Slovenian at /sl/, linked with hreflang, with / as the x-default; sitemap.xml lists both alternates of every page. The factory floor is drawn by JavaScript; without it, its text is only a JSON block. llms.txt gives a crawler that does not run JavaScript the same facts in Markdown, generated from the same en.json and factory-data.js as the page.

The request list

The source is not the proof; the browser's request list is. We loaded /, /sl/ and both privacy notices on the live site, and the news pages from a local build, in headless Chrome with a fresh profile and no consent, and recorded every request through the DevTools protocol. Every request went to the page's own origin, 7 to 16 per page. The Slovenian pages also fetched the latin-ext font files, for č, š and ž.

On the local build we then clicked “Allow analytics”. Two hosts appeared: one serves the Google tag script, the other the collection endpoint, with one request each per page. After “Decline” under “Cookie settings”, the _ga cookies were gone and the reloaded page again requested only its own origin.

For a team building on the toolkit: a consent banner is a claim, and the request list is its test. Before a product's landing page goes live, load it with a fresh browser profile and no consent, and read the hosts. If the page draws its content with JavaScript, generate a plain-text version from the same source, as llms.txt is here.

The harvest rule: when code moves into a kit

2026-10-11T00:00:00Z

A product builds what it needs in its own repository first. The question is when a piece becomes a kit. Too early, and we design for consumers that do not exist. Too late, and the copies drift: on 10 October one fix to the Keycloak setup reached Reputo and Leadgener as two merge requests, one per copy.

Two conditions, both required

We move code into a kit only when a second product needs the same behaviour and that behaviour must not diverge: security, legal obligations, operations or an API contract. If only the first holds, the second product copies the piece and owns its copy; the app shell, the login theme and the landing page stay copies for that reason. A kit needs at least two consumers within six months, or it goes back into its product.

A product, in turn, does not edit kit code: it pins a version, and a kit change is made in the kit and released. For the NuGet packages, all five products carry the same check in their CI file:

test ! -e libs/microsaas-toolkit || { echo "libs/microsaas-toolkit is back; change the toolkit in its own repository"; exit 1; }

The Keycloak kit, harvested

Reputo and Leadgener each carried a copy of the realm provisioning script, 347 and 348 lines long respectively. It sets what every realm must share, such as self-registration off and PKCE with S256 for browser clients. Leadgener's copy appeared on 8 October; three days later, beyond each product's defaults, the two differed in comments and one role description.

On 11 October 2026 we moved it into the Keycloak kit as a faithful port: the same values in, the same realm out, no cleanup in the same step. We ran each product's own scripts, then the kit, on a fresh Keycloak and compared the normalized realm exports. They were identical byte for byte, except for that role description, which a divergence file records with its reason.

Each product then replaced its copy in its own merge request. The provisioning script became a 46-line wrapper in Reputo and a 47-line one in Leadgener, holding only the product's defaults, and each product pins the kit's image by version and digest.

The Keycloak kit is therefore code that already ran in two products, ported so that it behaves as it did there, proved by tests a reviewer reads as a diff. When a kit does not do what you need, you do not patch it: you ask for an option, which arrives in a minor release with the old behaviour as the default, and you pin it when you choose. What no other product needs stays yours.

Leadgener from an empty repository: 45 hours to a dev environment

2026-10-10T00:00:00Z

Leadgener finds and tracks business opportunities in public sources. It started from an empty repository on 8 October 2026; it is still being built and runs only in a dev environment. A new product cannot be judged until it runs deployed, behind its own sign-in.

Copy the reference, change the palette

Leadgener's ADR-02, accepted on the first day, makes Reputo, our reference product, the source of truth for technology, patterns and components. Only the colour palette changes; any other deviation needs its own ADR.

The first commit held only product documents. Ten seconds later came the toolkit, vendored unchanged: 167 files, 11,414 lines. Twelve minutes in, the backend skeleton followed on Reputo's patterns, with tenancy, onboarding and organizations and without billing.

The next six hours went into Leadgener's domain: capturing notices from public sources, documents and a keyword dictionary, an evidence-based assessment with a selectable model provider, and screens to review the results. At hour 23 came the deploy, ported from Reputo: CI file, Dockerfiles, Compose file and deploy scripts.

Where the 45 hours went

Hour 30: the GitLab project was created; by choice, the repository stayed local until then.
Hour 31: on main the tests passed, then dotnet restore in the image build hung: NU1301 after ten minutes, still retrying half an hour later. Reputo had hit the same hang on 2 October and fixed it with docker build --network host: the Docker-in-Docker bridge has a larger MTU than the runner's network. The port had dropped the flag. One merge request restored it, and the images were built nine minutes after it merged.
Hour 45: deploy:dev is a manual job, and it waited 13.5 hours overnight. Then, in 1 minute 50 seconds, it started seven containers, created the Keycloak realm and passed a health gate of six checks: API, app, realm, login theme and two landing pages.

For a team starting a product on the toolkit, Leadgener's record is about two days to a deployed dev environment, and the work in them went mostly into the product. Later that day, Leadgener replaced its vendored toolkit with the NuGet packages, pinned to one version. The CI file and deploy scripts remained ported, and Leadgener's first pipeline shows the cost: the reference's CI file carried the flag with a comment explaining it, and the port dropped both. Diff your pipeline against the reference's before your first push to main.

19 packages, one version

2026-10-10T00:00:00Z

Before 1.0.0, each of our five products carried its own copy of the shared SaaS modules: tenancy, onboarding, organizations, entitlements, usage, billing and admin. The copies lived inside each repository, and the oldest was about eight months behind the newest. When we wrote the upgrade notes for the first release, Gostly needed one list, MojRazpis and SnapMind a longer one. A fix made in one copy reached the others only if someone carried it over by hand.

One version for every package

On 10 October 2026 we tagged v1.0.0 and published the shared code as 19 MicroSaas.Toolkit.* NuGet packages with a single version. One Directory.Build.props holds the build settings, and the tag pipeline passes -p:Version=X.Y.Z from the tag to every project, so the packages also depend on each other at that version. The publish job stops if CHANGELOG.md has no section for the version, or still marks it unreleased, and it counts what it packed:

[ "$count" -eq 19 ] || { echo "expected 19 packages, packed $count"; exit 1; }

The package registry is set to refuse a version it already holds, so 1.0.0 is the same code for every product.

In a product, the version is one property in its own Directory.Build.props:

<MicroSaasToolkitVersion>1.0.0</MicroSaasToolkitVersion>

Every toolkit PackageReference reads that property. Products reference different subsets: Leadgener 6 of the 19 packages; Reputo 16; Gostly, MojRazpis and SnapMind 17 each.

What it costs, and what it does not mean

The cost is written into our design: a product cannot take an Organizations fix without the Billing changes of the same release. With one maintainer, one version line is cheaper than nineteen, and the changelog makes the cost visible in advance. It flags each entry that needs action as [migration], [contract] or [behaviour], and lists, for each starting point, what a product has to change before it upgrades.

One version does not mean lockstep. A release never requires two products to upgrade together. Each product moved to 1.0.0 through its own merge request in its own repository. All five merged on the same day because all five were leaving their vendored copies, not because the release demanded it. The next release is a one-line change in whichever product wants it, made when that product chooses.

For a team building on the toolkit, that means one number to pin, the changelog sections between your version and the new one to read, and an upgrade on your schedule, not ours. Two products on different toolkit versions are both valid, because they share code, never a running instance.

Reputo on the toolkit: what came on day one, and what we built

2026-10-02T00:00:00Z

Reputo is for the marketing lead of a small business that sends its own campaigns. It says, in plain language, whether the company's email is arriving, what is wrong, and what to ask IT to change. It runs in a dev environment and is not in production yet.

Behind those answers sits a multi-tenant SaaS: organizations, members, plans, usage limits, an admin interface for the operator. A buyer pays for none of it, and all of it has to work before the first customer signs in.

Day one: the toolkit

Reputo's first commit, on 20 September 2026, held a domain-check core, rebuilt from earlier work, and a vendored copy of our toolkit. The same morning, the API ran against a real PostgreSQL database and listed 42 routes. Thirty-four came from the toolkit: onboarding, organizations, entitlements, usage, billing and admin. Of the 12 tables in the first migration, 11 were the toolkit's.

Reputo's AppDbContext derives from the toolkit's OrganizationDbContextBase, so every entity that belongs to an organization gets a tenant filter, and Reputo's queries over monitored domains rely on it. On the SaaS side, Reputo's own code that day was the wiring in Program.cs and its plans: Free, Pro and Business with their quotas, and a hook that gives each new organization the Free plan.

Twelve days: the product

The next twelve days went into Reputo's own code around that core: DMARC aggregate reports collected from a mailbox, per receiving provider; incidents with alert mail in Slovenian; integrations with Google Postmaster and Microsoft SNDS; and the screens. On 2 October main was first deployed to a dev environment. Keycloak did not start on the first attempt; the second, under half an hour later, passed the checks of the API, the app and the Keycloak realm.

For a team starting a product on the toolkit, the measure is where the first weeks go. In Reputo, tenancy, members, entitlements, usage limits and the admin endpoints were wired into the API on the first morning, and the twelve days to a dev environment went into the checks, reports and alerts its buyer would pay for.