DEV Community: GDS K S

Your deploy box is the target: supply chain defenses after this week's attacks

GDS K S — Thu, 12 Nov 2026 17:41:00 +0000

Your deploy box is the target: supply chain defenses after this week's attacks

I read the OpenSourceMalware report on Tuesday and then did something simple. I opened my own CI config and listed every secret a single build job could see. The attack it describes starts with a PR from a brand new account labeled "CI diagnostics" that sends environment variables to a remote URL.

The answer was uncomfortable. A build job on my side holds a registry token, a deploy key and a cloud credential, all in one shell. That is exactly the shopping list attackers wrote down this week.

TL;DR

What happened	Date	What it means for you
A stolen developer key pushed a dropper into `@ethersphere/bee-js` 13.3.0, and the publish workflow shipped it to npm and GitHub	Nov 9	Your release pipeline will publish whatever a valid key commits
A brand new GitHub account sent CI exfiltration PRs, a prompt injection for reviewers and a Rust crate with a `build.rs` stealer	Nov 10	Build scripts and PR checks run with your secrets in reach
Socket's hardening guide says most 2025 and 2026 CI compromises came through `npm install`, not workflow bugs	Nov 3	Install time is the weak spot, so lock it down first

1. What the two attacks actually did

OX Security reported on November 9 that attackers likely used a stolen developer access key to commit malicious code to the official bee-js and swarm-desktop repositories. The commit triggered the normal publish workflow, which created the npm release and the GitHub release. No one broke into the registry. The pipeline did its job with a bad commit.

The dropper then asked a command server for a payload matched to the victim's operating system. It uploaded the local Swarm node's encrypted key and config, then installed a backdoor. On Linux and macOS the backdoor looks up its server address from an Ethereum contract, so the attacker can move it whenever they like. OX counts about 16,800 monthly downloads of exposure. That is small. The pattern is not.

The second attack, written up by OpenSourceMalware on November 10, came from a GitHub account created about seven hours before the report. It ran four moves in a row. Two PRs tried to send environment variables and signing material out of CI. A third PR added a paragraph to AGENTS.md telling reviewers, including automated ones, not to flag those uploads. Another PR added a Rust crate, lwd-uri-util, whose build.rs gathers .git-credentials, .aws/credentials and .npmrc. Finally, a fake security disclosure sent two maintainers to a cloned sign-in page.

Read that list again if you deploy code. The target is not your app. The target is the box where your app gets built.

2. Why the build environment is the prize

A typical CI job carries a registry push token, a cloud credential and a deploy SSH key. It also runs arbitrary install scripts from hundreds of transitive packages. One malicious postinstall or build.rs inherits all of it.

The OpenSourceMalware report lists what the Rust stealer wants: GitHub, AWS, Cargo, npm, PyPI, Android signing keys and CI secrets. Its advice for anyone who built the affected branches is to revoke and reissue every secret present in that build environment. That is a long afternoon. The cheaper move is to make sure the build never holds most of them.

Here is the rule I now apply. A job that installs dependencies gets no deploy credentials. A job that deploys installs nothing.

Split install from deploy

name: release
on:
  push:
    tags: ["v*"]

permissions: {}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@<full-40-char-sha>
        with:
          persist-credentials: false
      - run: npm ci --ignore-scripts
      - run: npm run build
      - uses: actions/upload-artifact@<full-40-char-sha>
        with:
          name: dist
          path: dist/

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: production   # holds the deploy secret, needs approval
    steps:
      - uses: actions/download-artifact@<full-40-char-sha>
        with:
          name: dist
      - run: ./scripts/push-release.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

The build job sees no secret at all. The deploy job installs nothing, so a poisoned dependency never runs next to the token. The production environment can require a human approval before the second job starts.

3. Pins: tags move, digests do not

Socket's guide makes a point I keep repeating to people. Version tags are movable pointers. In the tj-actions/changed-files attack, pinning by commit SHA kept every repository safe. In the March 2026 trivy-action incident, Socket reports 75 of 76 version tags were force-pushed.

A SHA proves the content cannot change. It does not prove where the commit came from, because impostor commits from forks can still resolve. Pin, and read the diff when you bump.

Images work the same way. A tag like node:22 is a pointer. A digest is content.

# resolve once, on a machine you trust
docker buildx imagetools inspect node:22-slim | grep Digest
# Digest: sha256:<64 hex chars>

# then pin it in the Dockerfile
# FROM node:22-slim@sha256:<64 hex chars>

Do the same for the images you run, not only the ones you build. In a compose file:

services:
  web:
    image: registry.example.com/team/web@sha256:<64 hex chars>

I also keep to upstream-only namespaces. Pull library/postgres or the vendor's own namespace, not a lookalike from a stranger. Even a real namespace can be hijacked, so digests matter more than names. Names only remove the cheapest attacks.

Add a cooldown

Socket cites a Wiz estimate that a 7 to 14 day cooldown catches 80 to 90 percent of supply chain attacks, and notes Dependabot applies a three day cooldown by default on github.com. Ethersphere reverted the bad npm version only after it shipped. If your lockfile refuses anything published in the last week, you skip most of that window.

# .npmrc
ignore-scripts=true
min-release-age=7

Scripts then run only where you allow them. Check your npm version supports the release-age key before you rely on it, since Socket describes it as a setting for .npmrc and your update bot.

4. Cut what the token can do

Socket calls the write-scoped GITHUB_TOKEN the usual escalation step from a foothold to a real incident. Set permissions: {} at workflow level, as in the example above, and grant per job. Avoid pull_request_target with untrusted code. Pass PR titles through env: instead of inlining them in run: blocks. Run zizmor in CI to catch the rest.

Then treat registry tokens the same way. A publish token that only works for one package, with a short life, turns a stolen key into a small problem. The Ethersphere case shows the other side: a long-lived developer key plus an automatic publish workflow equals a release anyone with the key can ship.

5. Egress limits, with honest limits

The last layer is the one most people skip. When the stealer cannot reach its server, it collects secrets and has nowhere to put them. The Rust crate uploads to a public webhook endpoint. The Ethersphere dropper called a fresh .xyz domain registered two days earlier. A deny-by-default outbound list blocks both.

Socket's advice is to run an egress agent in audit mode first, build the allowlist from real traffic, then enforce. Socket also admits the limit: allowlisting cannot stop exfiltration to hosts you must allow, such as github.com. Egress is a way to cut damage, not a wall.

On the server that runs your apps, the same idea applies at runtime. If the web container only talks to your payment API, say so.

6. What we do about this

We built outbound allowlists and image pinning into Levelrail for the deploy side. Per the docs, Levelrail pins an image pulled from a registry to its digest at deploy time, APP_IMAGE_VERIFY_MODE=enforce refuses unsigned or unpinned images on promotion, and a service can declare an egress allowlist of host and port pairs. Two honest limits from the same docs: without the egress block the outbound traffic is open, and signature checks support cosign key pairs, not keyless signatures. Build-time secrets are opt in per secret for that reason.

What I changed this week

I did five things, in order of effort.

Moved deploy tokens out of any job that runs npm ci.
Pinned every action to a full SHA and every base image to a digest.
Turned on a seven day release-age floor and ignore-scripts.
Set permissions: {} as the workflow default.
Put the deploy job behind an approval.

None of it takes more than a day. The attacks this week were small: about 16,800 monthly downloads and one wallet-focused crate. The same techniques against a package with millions of installs would look different.

The Bottom Line

Attackers are skipping your code and going for the machine that builds and ships it. Split install from deploy, pin by digest, add a cooldown, shrink token scopes and limit outbound traffic. How many secrets does your slowest, most neglected CI job hold right now?

Sources checked

OX Security, Ethersphere compromise, Nov 9 2026: https://www.ox.security/blog/ethersphere-hijacked-with-crypto-stealing-malware-via-github-npm/
OpenSourceMalware, malicious Rust crate targeting wallet developers, Nov 10 2026: https://opensourcemalware.com/blog/cryptocurrency-being-targeted-in-multi-faceted-attack
Socket, Hardening GitHub Actions Against Outside Threats, Nov 3 2026: https://socket.dev/blog/hardening-github-actions-against-outside-threats
Levelrail docs: docs/images.md, docs/app-spec-reference.md

I redeployed an app three times while sending 4,000 requests. Two cut over, one is a mystery

GDS K S — Mon, 02 Nov 2026 18:37:33 +0000

"Zero downtime" is one of those phrases that sounds finished until you try to prove it. So I built a small load script and a rule: send steady traffic through the real HTTPS ingress, redeploy the app three times, and count every failed request.

The setup

A tiny web app (a whoami container) behind the platform's proxy, over HTTPS with a local certificate.
About 20 requests per second, for the whole run.
Three redeploys, each by API with a new image tag.
Default drain settings: 15 seconds of draining, then a 3 minute hold so you can roll back, and a stability check before the old container goes away.

The result

4,313 requests. 0 failed or non-2xx.
Latency: p50 5 ms, p95 68 ms, p99 208 ms.
Longest gap between two successful responses: 0.111 seconds.

I ran the same idea on a real 2 vCPU VPS too, at 10 requests per second: three redeploys, 458 requests, no failed responses, longest gap 0.36 seconds. A restart that waits for the app to be healthy took about 12 seconds each time, and roughly 8 of those seconds are the stability check deliberately making sure the new container is not a one-hit wonder.

The two things that did not go to plan

The disk guard refused my deploy. On the first attempt, the third deploy came back with a 507. The platform has a guard that refuses a deploy when the disk is too full, and my laptop disk was at 90 percent. The guard was right. I lowered its thresholds for the test and moved on. A deploy platform that says no before it fills your disk is doing its job.

One redeploy never answered. Of the three redeploys, two cut over cleanly. The third was accepted by the API but the new version did not answer within my three minute wait. No request failed, because the old container kept serving, but I do not know why the cutover did not finish. The log ends with a cancelled write at shutdown, and I have not investigated further. It might be the hold window, a slow image pull or a real stall. I would rather tell you that than pretend the test was perfect.

What I learned about testing zero downtime

Count failures, not vibes. A number like 0 out of 4,313 is the claim. Anything softer is marketing.
Look at the longest gap, not just the average. Averages hide a one second hole.
Test on a nearly full disk at least once. Real servers are rarely tidy.
Keep the unexplained result. It is the next bug.

The script is in the repo if you want to point it at your own setup. The platform is Levelrail, which I build and run my own sites on: https://github.com/glincker/levelrail

How do you check that a deploy really did not drop requests?

I tested my own deploy platform on a real VPS | Levelrail

GDS K S — Mon, 02 Nov 2026 18:36:58 +0000

I had 15+ sites spread across Coolify on a few VPSs, Vercel, an AWS EC2 container, ECS, RDS and Neon. Every VPS renewal turned into a migration weekend. So I built a self-hosted deploy platform called Levelrail, and before I moved my own sites onto it I ran it on two real servers: an Oracle free-tier ARM VM and a cheap VPS that also runs Coolify.

I expected small bugs. I got four that would have hurt real users. Here they are, in the order I found them.

1. Every local backup failed on a fresh install

I created a Postgres database, ran a backup and looked at the history. Every local backup on a default install failed with the same error: the backup folder did not exist.

On my laptop the folder had existed for months, so I never saw it. On a clean server the platform tried to write into a path nobody had created.

The fix was small: create the local backup root the first time it is used, and make the location a setting instead of a hardcoded path. The lesson was bigger. A backup feature that works only on the machine you built it on is not a backup feature. I now run every backup and restore on a clean server before I trust it.

2. The firewall panel showed nothing

I wanted a firewall page that tells you what is actually exposed on a host, not a list of settings. On the VPS it showed an empty table.

The reason: the host used nftables, and the panel only knew how to read the older iptables rules. It looked fine on every machine I had tested, and showed nothing on the one that mattered.

Now the panel detects which backend is active, reads it, and says so when it cannot. An empty security panel is worse than no panel, because it looks like good news.

3. After a reboot the apps were unreachable for about 30 seconds

Apps are bound to loopback ports and the proxy routes to them. After a reboot, some ports changed, and the proxy kept sending traffic to the old ones until the next refresh.

On the Oracle ARM VM, Docker brought the containers back about 19 seconds after boot and the control plane answered health checks at 33 seconds. But Docker had handed two apps new loopback ports, and the platform kept the old ones for about 30 seconds until its next reconcile. I added a refresh at boot so routes recover as soon as the containers are back.

4. The HTTP to HTTPS redirect dropped the port

On a server where the proxy listened on a non-standard port, the redirect sent people to the default HTTPS port and the page failed. Small bug, very confusing for the person on the other end.

What the testing taught me

Test on a clean server, not your own. Three of the four bugs only appear where nothing is pre-configured.
A security or backup panel needs a loud "I cannot tell" state.
Write the failure into the product: the platform now tells you when a backup has failed instead of waiting for you to look.

How I test now

Before I trust a feature, I run it three ways: on my machine, on a clean cloud VM, and again after a reboot. The reboot is the one people skip. Backups, routes, certificates and firewall state are all things that look fine until the machine restarts and has to rebuild them from nothing. If a feature survives a clean install and a reboot, it has earned a place in the product.

The numbers

Control plane memory: about 200 MB RSS right after start (196 MiB on the VPS), and the API was ready in 4.2 seconds from an empty data directory.
A Next.js 14 app built and deployed in 2 minutes 46 seconds on a 2 vCPU VPS, with a peak of about 514 MB of extra host memory during the build.
A restart with --wait takes about 12 seconds. Three redeploys under 10 requests per second served 458 requests with no failed responses and a longest gap of 0.36 seconds.
Upgrading the platform in place: 2.19 seconds of downtime, a 179 ms database migration, and all 5 apps, 7 databases and 6 domains still there afterwards.
A new Postgres database was ready in 7.2 seconds, and a restore into a new database took 22 seconds with all 1000 test rows intact.

What Levelrail is

It is a self-hosted deploy platform. Deploy from Git, a Dockerfile, a compose file or a template. HTTPS and domains, logs, rollbacks, databases with scheduled backups and restore, multiple servers from one control plane, and an audit log. Everything is also available from the CLI, the API and an MCP server. I run my own sites on it.

Repo: https://github.com/glincker/levelrail
Site: https://levelrail.com

If you self-host and have a bug you only found on a clean server, I would like to hear it. What did your first failed backup look like?

I ran Minecraft, WordPress and MySQL on a free 6 GB ARM VM and watched the RAM | Levelrail

GDS K S — Mon, 02 Nov 2026 18:36:26 +0000

Free tier servers are a great way to find out what your tools really cost. I took an Oracle Cloud ARM VM with 6 GB of RAM, put a self-hosted deploy platform on it, and asked it to run four things at once: a developer toolbox, WordPress, MySQL and a Minecraft server. Then I rebooted it twice and wrote down what happened.

glincker / levelrail

Self-hosted alternative to Vercel and Coolify. Git push, HTTPS, logs, rollback. No Kubernetes.

Levelrail

Self-hosted PaaS: deploy on git push to your own servers, with logs, metrics, HTTPS and rollback.
One Go binary, Docker runtime, no Kubernetes. Apache 2.0.

Website · Docs · Install · Production ready · Compare · FAQ · Roadmap · Changelog · Discussions

English · 简体中文 · Español · Português (BR) · Deutsch · Français · 日本語

Levelrail is an open source (Apache 2.0) self-hosted PaaS for developers and small teams who want a Vercel, Heroku or Railway style workflow on servers they own. It runs on any Linux server, from a small VPS to a rack (the one measured host is a 2 vCPU, 8 GB box), and turns plain servers into a private cloud with Git deploys (forge webhooks), HTTPS, databases with verified backups, metrics, logs and alerts, without Kubernetes and without the monitoring stack you would otherwise bolt on.

Status: pre-1.0 (v0.x). Single-server is production ready…

View on GitHub

The cast

it-tools, a static toolbox app. It used about 2.3 MiB of RAM and answered in 1 ms. Basically a rounding error.
WordPress and MySQL 8.4. 33 MiB for WordPress, 467 MiB for MySQL. MySQL is the one that always shows up with a suitcase.
Minecraft (Java 21). 2.24 GiB out of a 2.5 GiB limit, 97 percent right after start. No out-of-memory kill. Java will use every byte you hand it and then ask what is for dessert.

The install command returned in under a second because the work is asynchronous. All four containers were up, and Minecraft was healthy, about 107 seconds after I submitted the request, image pulls included. Host memory went from 0.7 GB to 3.4 GB and stayed there, with about 2.4 GB still available.

Watching a boot, second by second

After a clean reboot I sampled memory as the machine came back:

Time after boot	Used memory
39 s	1.27 GB
60 s	3.2 GB (the JVM and MySQL waking up)
steady	3.35 GB

SSH came back 28 seconds after I issued the reboot. Docker started the containers at roughly the 19 second mark, the control plane answered its health check at 33 seconds, and Minecraft was healthy at about 80 seconds. Available memory never dropped below 2.5 GB.

The reboot that fought itself

The first reboot did not go well. The new control plane would not start: Address already in use on port 80. The old install I had left on the same machine was still enabled, and its sockets grabbed the port first. Two versions of the same platform, fighting over the front door.

Here is the funny part. While the control plane was not running at all, Docker restarted all four app containers on its own, 9 seconds after boot, because they carry a restart policy. The apps were up and serving before the thing that manages them had started. That is what you want: the apps should not depend on the control plane being alive.

I disabled the old service and rebooted again for the clean run above.

Two rough edges I found

After the reboot Docker assigned new loopback ports to two apps. The platform remembered the old ones for about 30 seconds until its next reconcile, which means a proxy pointed at a stored port would have returned errors for half a minute. I fixed it by refreshing the ports at boot.
Minecraft logged two scary looking health check errors while it was starting, 35 seconds apart. They fixed themselves, and they made the logs noisy. Noise like that trains you to ignore the real alarm.

What I took from it

A 6 GB free VM is plenty for a small stack. It is not plenty for a stack with a JVM in it unless you set a memory limit. I did.
Measure the boot, not just the steady state. The peak is at about 60 seconds, and that is when things fall over.
Restart policies on the apps and a small control plane make reboots boring, which is the goal.

The platform I used is Levelrail, which I build and run my own sites on: https://github.com/glincker/levelrail

What is the most RAM-hungry thing you run at home?

Your logos folder is already out of date

GDS K S — Mon, 02 Nov 2026 18:36:18 +0000

Open your project and look for a folder named logos, brands or partners. It probably holds a couple of dozen SVGs you downloaded one at a time, with names like github-new.svg, stripe-2021.svg and slack_final_v2.svg.

That folder was correct on the day you made it. It has been drifting ever since, and nothing in your build will tell you.

I learned this the hard way. Our template catalog showed a logo for 63 of 442 apps, because someone copied 63 files by hand and nobody wanted to copy the rest. The other 379 tiles showed a gray letter. The marks existed. They just lived somewhere else.

What goes wrong with hosted logo files

Copying a file gives you a snapshot. Brands do not stand still, and a snapshot has four ways to go bad.

The brand changes its logo, and your site keeps showing the old one.
The file was never clean. It has a hard-coded size, no viewBox, a script tag, or a "mono" version that secretly uses four colors.
Each file is a one-off, so no two have the same name, the same dark mode story or the same license note.
Nobody owns it. A designer drops a file in, a developer renames it, and nobody can say where it came from.

A hosted folder also costs you bytes you cannot see. A sprite sheet of every logo you might need loads on the page that needs only one.

The fix: treat logos like a dependency

You already treat React, your date library and your CSS framework this way. Somebody else maintains them, you pin a version, and you upgrade on purpose. Brand logos can work the same way.

theSVG is an open catalog of more than 7,600 brand icons with a rule that every icon follows the same path scheme: {slug}/{variant}.svg. The GitHub logo is always github. Its dark version is always github/dark.svg. When the brand changes the mark, the new one lands under the same name.

That one rule is what makes updates automatic.

Seven reasons a library beats your own folder

The first reason is the one that matters most. The other six are what keep it that way.

Reason	What it means for you
Same name, new icon	A rebrand ships in a version bump, with no code change
One naming scheme	`default`, `mono`, `light`, `dark` and `wordmark` everywhere
Checked in CI	No scripts, no raster data, a real `viewBox`, mono files that are truly single color
Rebrands keep history	The old mark stays as a `-legacy` entry, so nothing vanishes
Tree-shaking	Import one icon and ship one icon
License on every entry	You can see the rules before you ship
Signed releases	npm packages publish with provenance

The checks are not decoration. Last week we added 27 new self-hosted app icons to theSVG, and the validator rejected our first pull request. Six files carried editor metadata, and one "mono" variant was not single color. The bad files never reached a release.

How to check how stale your folder is

You can find out in ten minutes. List every file in the folder and ask three questions about each one.

First, where did it come from? If the answer is "a Google image search," treat it as untrusted. Second, does it open cleanly? Run it through an SVG linter and look for a missing viewBox, a fixed width and height, or embedded PNG data. Third, is it still the brand's current mark? Open the company's own site next to your copy and compare.

Most folders fail at least one of those checks. The failures are rarely dramatic. A slightly different blue, a retired gradient, a wordmark with the old typeface. Visitors rarely notice any single one, but together they make a page look less cared for.

Setup in five minutes

Pick the line that matches your stack.

# React
npm install @thesvg/react

# Astro
npm install @thesvg/astro

# Plain JavaScript, tree-shakeable
npm install thesvg

# No install, copy one icon into your repo
npx @thesvg/cli add github

Then use an icon the way you use any component. The variant prop picks the light, dark, mono or wordmark version, so dark mode is one prop instead of a second file.

import Github from "@thesvg/react/github";

export function Footer() {
  return <Github width={24} height={24} variant="dark" aria-label="GitHub" />;
}

In Astro, the import path is the same idea.

---
import Github from "@thesvg/astro/github";
---
<Github size={24} />

If you only need an image tag, the CDN works with no install at all.

<img src="https://thesvg.org/icons/github/default.svg" width="32" height="32" alt="GitHub" />

Let your tools do the updating

The real payoff is the part you stop doing. Add the package to Dependabot or Renovate and a new icon version arrives as a normal pull request. Your logos improve while you work on something else.

We did this on our own product. The dashboard used a hand-kept list that matched each of 442 app templates to a logo file. We replaced it with a small script that reads the template ids, checks which marks exist in the installed package and writes the mapping. Now a version bump of @thesvg/react is the whole job. Version 4.0.3 added 27 icons, which unlocked 34 more tiles without adding a single file.

What about brands that are not there yet

Tell us, or add them yourself. Every icon starts as a pull request with the SVG and a small data entry, and the same checks run on yours. If a project is real, it belongs in the catalog. The library is open source under the MIT license, with no accounts and no API keys.

You can also ask your AI editor. The @thesvg/mcp-server package lets your AI editor look up and insert logos for you, so you never have to leave the file you are editing.

Try it on one file

Do not migrate everything today. Pick one component that imports a logo from your logos folder, swap it for the library version, and delete the file. If you like the result, do the next one.

If theSVG saves you a trip to a press kit, a star on GitHub is the best way to help other developers find it.

glincker / thesvg

The open SVG brand library: 7,600+ brand logos and cloud icons (AWS, Azure, GCP) as official SVG. Search, copy, ship via npm, CDN, CLI, React, Vue, Svelte, Figma, VS Code, Raycast and MCP. Free, MIT, no gatekeeping.

The open SVG brand library

A HOME FOR EVERY BRAND.

7,600+ brand logos and cloud icons. Search, copy and ship them as SVG, React, Vue, Svelte, CDN, CLI or MCP.
Free, open source, no gatekeeping

Browse icons • Quick start • Install • Extensions • CDN • API • Packages • Compare • Community • Contribute • Contributors

Every logo below is served straight from theSVG.

Why theSVG

Brand logos are scattered across press kits, Figma files, and random GitHub repos. theSVG is the single source for SVG icons - brand logos, cloud architecture diagrams, and a set of interface icons of our own. Searchable, versioned, and available as npm packages, CDN, CLI, API, and MCP server.

Every developer has hunted for a company logo: a press kit buried three clicks deep, a PNG that blurs on retina, a "mono" file that is secretly four colors, a logo that changed…

View on GitHub

Which logo is the most out of date in your project right now? Tell me in the comments, and I will check whether theSVG already has the new version.

Zero Downtime Deploy for Docker Apps, With Rollback

GDS K S — Mon, 02 Nov 2026 00:11:48 +0000

After this guide you know exactly what stands between a deploy trigger and live traffic on Levelrail, a self-hosted deploy platform, and you can roll back a bad release in one command. "Zero downtime" holds only if three smaller things hold. Something checks the new version before it gets traffic. The old version is still around if you change your mind. And the platform can tell whether the thing running is the thing you shipped.

For a hands-on run with measured request counts, see restart a Docker container without downtime and roll back a failed Docker deploy.

Checked on 2026-11-01 against the current Levelrail release.

Zero downtime deploy guarantees at a glance

Guarantee	What it prevents
Readiness gate before cutover	Traffic hitting a container that is not ready
Stable window	A container that starts, then crashes
Digest-truthful deploys	A redeploy of the same tag silently keeping old content
Stale-deploy guard	An older build overwriting a newer one
Previous release held after cutover	A slow, cold-start rollback
Post-deploy watch	A bad release that passes readiness, then fails under load
Freeze windows	Friday-afternoon deploys

The deploy sequence for a Docker app

start new container
      |
readiness probe passes N times in a row, container stays up for the stable window
      |  fail: old container keeps serving, deploy fails with a reason
      |
cut traffic to the new release
      |
drain the old release (at least 15s by default)
      |
hold the previous release for instant rollback
      |
watch the new release for 5 minutes

A new container takes traffic only when its readiness probe passed twice in a row (APP_DEPLOY_SUCCESS_THRESHOLD) and it ran for 10 seconds (APP_DEPLOY_STABLE_WINDOW) without exiting, restarting or being OOM-killed. If the gate fails, the old release keeps serving and the deploy records a reason such as ReadinessFailed, ExitedDuringReadiness or OOMKilledDuringStableWindow. The recreate strategy is the exception, since it stops the old release first.

Set the probe in your app spec and keep the route cheap:

health:
  readiness: { path: /healthz, interval: 5s, timeout: 2s }

A readiness check that calls three outside services fails for reasons your release did not cause. For why a passing check can still hide a dead app, read health checks that pass on a dead container.

To watch a deploy go through its gate:

levelrail-cli deploy status web --watch
levelrail-cli apps deploys gate web dep_abc123

Why a floating tag can lie

Deploy nginx:latest twice and the tag points at different content over time. A platform that compares tags can report success while the old image keeps running. Levelrail resolves the tag to its content digest at deploy time and pins the desired image, like nginx:latest@sha256:3f1c.... New content gets a new container and goes through the normal cutover. Levelrail tracks builds by the local image ID, so rebuilding the same commit on a newer base image replaces the container.

The controller then checks that the running image ID matches the pinned reference. On a mismatch the app reports Ready: False with ImageDigestMismatch, and the previous release keeps serving.

To refuse a cached fallback when the registry is down, deploy with --pull:

levelrail-cli apps deploy web --pull

Old builds should not win

Webhooks arrive out of order. Every automatic deploy gets a per-app sequence number and the commit ordering from your git provider. A deploy triggered earlier than one already applied becomes superseded, and so does a push whose commit predates the deployed one. Manual deploys and explicit rollbacks are never rejected, and they advance the sequence, so an older build in flight cannot undo your rollback. Deploys of one app run one at a time, and queued deploys survive a control plane restart.

Roll back a Docker deploy

levelrail-cli apps deploys list web
levelrail-cli apps deploys rollback-to web dep_abc123

History rows store the pinned reference, so a rollback deploys exactly the content that row ran, even if the tag moved. It also restores that deploy's literal env values, port, health checks, replicas and resources. Secret and database references keep their current values. The rollback is an ordinary deploy and passes the same readiness gate. The dashboard has a Roll back to this action on each history row.

After a successful cutover, the previous release stays running. The hold is the longest of APP_DEPLOY_PREVIOUS_RELEASE_HOLD (3 minutes), the drain timeout and the post-deploy watch window (5 minutes), so with defaults it lasts about 5 minutes. Rolling back inside that window needs no pull and no cold start. Levelrail keeps one previous release, so five deploys in a minute leave the current release plus one.

The API answers 410 when the old local image no longer exists, and 409 when its tag now points at other content. Levelrail keeps the newest three rollback pins per app (APP_DEPLOY_ROLLBACK_PINS), and image cleanup never removes a pinned image. Raise the value for a longer safety net.

Automatic rollback after cutover

For five minutes after cutover (APP_DEPLOY_WATCH_WINDOW), Levelrail watches the release. It trips on an OOM kill, on restarts reaching the limit (default 2), or on a 5xx share of 20% after 20 requests. The mode is notify by default, which alerts. Set auto to roll back to the last good release:

levelrail-cli apps watch set web --mode auto --watch-window 10m
levelrail-cli apps watch get web

A latency regression is a soft signal that only alerts unless you opt in. A release that is itself an automatic rollback is never rolled back again.

Freeze windows

A freeze window starts at every match of a cron expression in a timezone and lasts a set duration:

levelrail-cli apps freeze set web --cron "0 17 * * 5" --duration 64h \
  --timezone Europe/Berlin --reason "weekend freeze"
levelrail-cli apps deploy web --image app:hotfix --override-freeze --override-reason "CVE fix"

Levelrail holds push webhooks and replays them when the window ends, and only the newest replays. Manual deploys get a 423 unless they carry an override and a reason.

What can go wrong

Symptom	Cause and fix
Deploy fails, old release still serves	The readiness gate failed. Read `apps deploys show web` for the reason and the last 200 log lines.
Rollback returns 410	Image cleanup removed the old image. Redeploy from source and raise `APP_DEPLOY_ROLLBACK_PINS`.
Rollback returns 409	The tag moved or the row has no digest. Redeploy a known image.
Short outage on a deploy	A pinned host port or a single replica with a writable volume cannot run two releases. Levelrail stops the old one first.
Deploy shows Held (frozen)	A freeze window is active. Wait, or override with a reason.

What I have not verified yet

The project's live test ran a good release, a crashing release and a 5xx release against a real ingress on Docker Desktop: 2,617 requests, none failed outside the bad release's own 500s. I have not repeated that on a production VPS. On remote nodes, the running image ID, rollback pins and restart counts do not yet travel over the agent transport, so mismatch detection and some gate checks apply to the control plane's own node.

FAQ

How long is the previous release kept?

About 5 minutes with defaults. The longest of the hold, the drain timeout and the watch window wins.

Does a rollback pull the image again?

Not inside the hold window, and not when the pinned image is still local.

What if my app drops requests on shutdown?

The old release drains, but it must handle SIGTERM. See graceful shutdown for Node apps in Docker.

Where next?

Read the design behind this in Docker orchestration without Kubernetes. Reference: Deploy safety, Deploy failures and Deploying and managing apps.

Levelrail is open source under Apache 2.0. If this saved you time, a star on the repo helps other self-hosters find it.

Protecting an MCP server in Go with OAuth 2.1

GDS K S — Sun, 01 Nov 2026 08:24:00 +0000

Protecting an MCP server in Go with OAuth 2.1

By the end of this post you will know how to put OAuth in front of an MCP server written in Go. You will publish the metadata clients need, reject calls without a valid token, and allow each tool only for the scopes you choose.

Disclosure: I maintain theauth-go, the library used here. The project is about four months old and has 6 GitHub stars, and I point out where that matters. Everything below comes from its repo docs and code. For the normative text, read the MCP authorization spec (I cite the 2025-11-25 revision) and the RFCs linked below.

Repo: glincker/theauth-go (MIT licensed Go library). Docs: docs.theauth.dev/go.

My question is narrow. You wrote an MCP server in Go. A client, perhaps an AI agent acting for a person, connects and asks to run a tool. How does your server know who is asking, and whether this call may run?

TL;DR: the flow in five steps

The client calls your MCP server with no token and gets a 401.
The WWW-Authenticate header in that 401 carries a resource_metadata URL.
The client reads your protected resource metadata (RFC 9728) and learns which authorization server to use.
The client gets an access token from that server (authorization code with PKCE S256).
The client retries with Authorization: Bearer <token>. Your server checks the token, then checks the scope for the tool you are running.

How does MCP authorization work?

A normal API has a known login page. An MCP client does not know your server in advance. It might be a desktop app connecting to a URL a user pasted in. Your server has to say, in a machine readable way, "here is who can give you a token for me."

That is what RFC 9728 protected resource metadata is for. Your MCP server publishes a small document at a well-known path. In theauth-go's docs, a resource identifier of mcp.example.com/api/mcp (served over HTTPS) gets this URL:

mcp.example.com/.well-known/oauth-protected-resource/api/mcp

Note where /.well-known/ goes: between the host and the path, not at the end. A resource with no path uses the bare /.well-known/oauth-protected-resource. This is the detail that bites people who build the URL by appending.

The authorization server has its own document under RFC 8414. For an issuer of auth.example.com/tenant1, clients fetch /.well-known/oauth-authorization-server/tenant1. theauth-go also serves /.well-known/openid-configuration/tenant1 with the same document.

Here is the whole exchange:

MCP client                    MCP server (resource)        Authorization server
    | POST /api/mcp  (no token)       |                              |
    |-------------------------------->|                              |
    |  401 WWW-Authenticate: Bearer   |                              |
    |  resource_metadata=".../.well-known/oauth-protected-resource/api/mcp"
    |<--------------------------------|                              |
    | GET resource metadata           |                              |
    |-------------------------------->|                              |
    | GET authorization server metadata (RFC 8414) ----------------->|
    | authorization code + PKCE (S256), ask for scopes ------------->|
    |<----------------------------------------------- access token  |
    | POST /api/mcp  Authorization: Bearer <token>                   |
    |-------------------------------->| check token and scope        |

The first step is the one to remember. The 401 points the client at your metadata, so a client that knows nothing about you can find everything else. In theauth-go's mcpresource module every challenge includes that URL. The host in it comes from the incoming request, so it stays correct behind a proxy that sets the standard forwarding headers.

Which authorization server can issue the tokens?

Any compliant one. If you use theauth-go, the same library can host it. Its authorization server speaks OAuth 2.1 with PKCE S256, and also supports DPoP (RFC 9449), token exchange (RFC 8693) and the device grant (RFC 8628). You need none of those for a first deployment.

The snippet below comes from the README quick start. I left out imports and the agent parts, and encryptionKey is a 32 byte []byte you load yourself. It declares your MCP server as a protected resource with its scopes:

a, err := theauth.New(theauth.Config{
    Storage:       memory.New(),
    BaseURL:       os.Getenv("AS_BASE_URL"),
    EncryptionKey: encryptionKey, // 32 bytes, load from your secrets manager
    AuthorizationServer: &theauth.AuthorizationServerConfig{
        Issuer: os.Getenv("AS_BASE_URL"),
        Resources: []theauth.ProtectedResource{
            {Identifier: os.Getenv("MCP_RESOURCE"), Scopes: []string{"read", "write"}},
        },
    },
})

Use a persistent storage backend (the README lists SQLite, Postgres and MySQL) instead of memory for anything beyond a demo. The resource identifier and the scopes are the contract between the two sides.

How do I verify tokens in a Go MCP server?

mcpresource is a separate Go module with zero dependencies outside the standard library, so a resource server does not import the whole library. The snippet is the repo's examples/mcp-server, abridged. I dropped imports and main, and replaced the example's small envOr helper with plain os.Getenv calls.

v := mcpresource.New(
    os.Getenv("MCP_RESOURCE"),
    mcpresource.WithJWKS(os.Getenv("MCP_JWKS_URI")),
    mcpresource.WithIntrospection(os.Getenv("MCP_INTROSPECT_URI"), os.Getenv("MCP_CLIENT_ID"), os.Getenv("MCP_CLIENT_SECRET")),
)

for _, d := range v.Diagnostics() {
    log.Printf("[mcpresource %s] %s (code: %s)", d.Severity, d.Message, d.Code)
}

r := chi.NewRouter()
r.Use(v.Middleware)

r.Get("/tools", func(w http.ResponseWriter, r *http.Request) {
    p, ok := v.Principal(r.Context())
    if !ok {
        http.Error(w, "no principal", http.StatusInternalServerError)
        return
    }
    _ = json.NewEncoder(w).Encode(map[string]any{
        "subject":     p.Subject,
        "actor":       p.Actor,
        "actor_chain": p.ActorChain,
        "scope":       p.Scope,
    })
})

Three details matter here.

mcpresource.New takes your resource URI first. The options say how to verify tokens: a JWKS URL for signed tokens, and an introspection endpoint with the resource's client credentials.

Diagnostics() reports configuration problems at startup. Log them there rather than discover them in production.

v.Middleware is the line that makes the router protected. A missing or bad token gets a 401 with the metadata pointer.

The Principal has Subject (the human), Actor (who is calling) and ActorChain. The package docs say ActorChain lists the agents between the human and the caller, so log both. A tool call from an agent is never just "user 42". It is "agent X acting for user 42".

How do I protect an MCP tool with scopes in Go?

Authentication answers who. Scopes answer what. The mcpresource source documents this guard, mounted after the middleware:

r.With(v.RequireScope("files:write")).Post("/tools/save", save)

A principal missing the scope gets a 403. The response carries WWW-Authenticate: Bearer error="insufficient_scope", a scope parameter listing what is required, and the resource_metadata URL again. Because the response names the scopes, a client can ask for exactly those on re-authorization. That suits an agent that should request more access only when a call needs it.

If you prefer one table for all tools, the package example checks it by hand. I abridged it to the handler body, after reading the principal p:

toolScope := map[string]string{"logs.read": "logs:read", "deploy.create": "deploy:create"}

need, known := toolScope[tool]
if !known || !slices.Contains(p.Scope, need) {
    http.Error(w, "tool not permitted", http.StatusForbidden)
    return
}

My rule either way: an unknown tool gets denied. Default to no. The Protect MCP tools guide covers this in more depth.

Limits, stated plainly

The first limit is age. theauth-go's first commit was in June 2026, and mcpresource ships in the same repo. Six stars means little outside use. Run it against your own client before you trust it, and pin the version.

The second is the scope of my claim. I have not run a conformance test of every MCP client against it, so I will not say every client works. I can only point to the RFC behaviors the code and docs describe.

Third, you can do this without my library. The pieces are standard: serve the metadata document, return the right challenge, and check bearer tokens with a JWT library and your authorization server's keys. If you already run an authorization server such as Hydra or Dex, you may only need the resource side, written by hand or with a small module like mcpresource. Wanting less code to own is a reason to use a library, not a requirement.

Fourth, the example checks tokens but does not decide your policy. Which scopes exist, which agent may get which, and when a human must approve are design decisions the library cannot make for you.

The bottom line

MCP authorization comes down to three moves. Publish protected resource metadata so clients can find your authorization server. Check the bearer token on every request. Check a scope per tool, and answer 403 with the scopes you need when it is missing. The mcpresource module covers the second and third with one middleware line and one guard per tool.

If you try it, start with examples/mcp-server in the repo, point it at a throwaway authorization server, and tell me what broke. What would you want a resource server library to check that this one does not?

If you want to read the code or try it, the repo is here:

glincker / theauth-go

Self-hosted Go authentication library. Embeds in net/http, chi, Gin, Echo or Fiber. OAuth 2.1 authorization server, MCP authorization (RFC 9728), passkeys, SAML, SCIM, TOTP, magic links, DPoP. SQLite, Postgres or MySQL. MIT, no hosted service.

theauth-go

OAuth 2.1 and sign-in for Go MCP servers and agents. It mounts into your own net/http server, your users and tokens stay in your own database, and there is no hosted service. MIT licensed.

Building an MCP server in Go means implementing OAuth 2.1, protected resource metadata (RFC 9728), PKCE and token validation yourself. This library does that part, so your server accepts tokens from MCP clients and you keep control of identity.

Checked against a real client. The official modelcontextprotocol/go-sdk client (v1.8.0) completes the full flow against it in integration/mcp-interop: discovery, dynamic client registration, PKCE S256, token exchange and an authenticated tool call. Login and consent are simulated in that test, so it proves the protocol path, not a production deployment.

Who it is for: Go developers building MCP servers, agent backends or internal tools who want to own their auth instead of renting it.

What you…

View on GitHub

GDS K S · thegdsks.com · building Glincker · follow on X @thegdsks

An MCP server that cannot say who is calling and what they may do is just an open port with a nice name.

I built a self-hosted AI list that checks itself weekly

GDS K S — Sat, 31 Oct 2026 06:35:15 +0000

Self-hosted AI moves fast. A list that was right in March has dead links by June, and nobody notices until they try to install something.

So I built a list that checks itself. awesome-selfhosted-ai has 166 open-source projects you can run on your own hardware: local LLM runtimes, chat UIs, agents, MCP servers, RAG and vector databases, speech, image generation, document OCR, voice agents and more.

glincker / awesome-selfhosted-ai

Curated list of self-hosted open-source AI: local LLMs, chat UIs, agents, MCP servers, RAG, speech and image generation. Health-checked weekly, dead projects removed automatically.

Awesome Self-Hosted AI

Open-source AI you can run on your own hardware or server.

303 projects across local LLMs, chat interfaces, agents, MCP servers, RAG, speech and image generation. A weekly job checks every project against the GitHub API, and anything archived, deleted or silent for over a year moves to UNMAINTAINED.md.

303 projects | 302 active in the last 90 days | 10.5M combined stars | 0 unmaintained | refreshed 2026-10-31

See the live health table for stars, last push and license per project.

View on GitHub

How it stays current

A weekly GitHub Action reads every project's repo through the GitHub API and records stars, last push, license and status. If a project is archived, deleted, or has had no push for a year, it moves to a separate Unmaintained file on its own. If it comes back to life, it comes back to the list. Nothing depends on me remembering to prune.

What is in it

16 categories, from LLM runtimes to voice agents and home AI.
A live table with stars, last push, license and a colored status badge per project.
A source-available section for popular tools whose license adds terms beyond a standard open-source one (n8n, Open WebUI, Dify and similar). The license is shown, so you can check it before commercial use.
Rising projects that are under a year old, which older lists tend to miss.
Rules I kept

Open source (or clearly labeled source-available), self-hostable, not archived, pushed to within 90 days, at least 500 stars. One project per pull request, and the README is generated from one data file, so a pull request is a small JSON change that CI validates.

Honest note

I used AI tools to help find candidates and draft descriptions. A script verifies every repo against the GitHub API, and I review the list. If you spot a wrong license or a dead project, open an issue and it gets fixed.

Link: https://github.com/glincker/awesome-selfhosted-ai

What is missing? Tell me which project should be in it.

Five Go auth libraries I would look at in 2026

GDS K S — Sat, 31 Oct 2026 05:22:06 +0000

Five Go auth libraries I would look at in 2026

Disclosure first: I maintain theauth-go, one of the five Go auth libraries below. The project is about four months old and has 6 GitHub stars. The other four have years of history and far more stars. I'll give a snapshot of each, say which job it fits, and tell you plainly when another one is the better pick.

Repo: glincker/theauth-go (MIT licensed Go library). Docs: docs.theauth.dev/go.

"Go auth library" covers at least five different jobs, and most bad comparisons mix them. A social login helper and an OAuth 2.0 server SDK share little except the word auth. So I picked five libraries with five distinct shapes instead of ranking them. Treat this as a list to look at, not a verdict.

Which Go auth library fits which job? The short version

Stats come from the GitHub API, pulled on 2026-10-30. Stars move, so treat them as a snapshot.

Library	Stars	Created	Last push	License	What it is for
ory/fosite	2,631	2015-12	2025-11-20	Apache-2.0	Building an OAuth2 and OpenID Connect server, no user management
aarondl/authboss	4,201	2015-01	2026-07-10	MIT	Modular web sign-in, confirm and recover flows
markbates/goth	6,620	2014-10	2026-02-11	MIT	Social login against a list of providers (client side)
go-webauthn/webauthn	1,357	2021-12	2026-10-29	BSD-3	WebAuthn and passkeys only
glincker/theauth-go	6	2026-06	2026-10	MIT	Sign-in, an OAuth 2.1 server and MCP authorization in one library

1. When to use fosite: you need to be an OAuth2 server

The fosite README calls it a security first OAuth2 and OpenID Connect framework for Go, built on the IETF RFCs. The protocol machinery comes in the box. You supply the storage and the story about who your users are. The pkg.go.dev page has the API.

Pick fosite when your product issues tokens to other people's apps. It has a history back to 2015 and a README that names the RFCs it follows. For that job it is the more established choice.

Know the tradeoff. Fosite is a toolkit, so expect to write the glue: storage, consent screens, login. It won't hand you a sign-in page. Its last push in the snapshot was November 2025, which isn't stale for a protocol library, but check the issue tracker for the features you need.

2. When to use authboss: classic web sign-in

Authboss describes itself as a modular authentication system for the web. You enable the modules you need and leave out the rest. Its README table of contents covers use cases such as resetting a password, and it says the library should integrate with or without any web framework. Package docs are on pkg.go.dev.

Pick authboss for a server-rendered site where users sign up, confirm an email and recover a lost password. You get those flows written once by someone else. It has been around since 2015.

You will write its storage and user interfaces yourself. Its README lists CSRF protection and request throttling as things your app must bring. If you also need an OAuth server or passkeys, you will be bolting on other pieces.

3. When to use goth: users arrive from other providers

Goth is the oldest and most starred library here. Its README lists a long set of providers, including Google, GitHub, Apple, Okta and OpenID Connect with auto discovery. If yours is missing, you implement its Provider and Session interfaces.

Pick goth when the whole job is "Sign in with X" and you already have your own user table. It stays out of your storage and session design, which is a feature if you have opinions there.

Goth is client side by design. It talks to other providers. It does not make you one, and it does not manage passwords or MFA. The last push in the snapshot is February 2026, so test the provider you need before you commit.

4. When to use go-webauthn: passkeys are the job

The go-webauthn README says the library handles Web Authentication for Go apps that want multi-factor, passwordless or usernameless sign-in. It also says the library is conformance tested against the relevant tools. The protocol itself is specified in the W3C Web Authentication spec. The last push came the day before my snapshot.

Pick it when you already have an auth system and want to add passkeys properly. It does one thing, and that narrowness is the point. You wire the ceremonies into your own session handling.

If you wanted a full system, this is a building block. That is fine, as long as you know it going in.

5. When to use theauth-go: one embedded library

This one is mine, so read with that in mind. The theauth-go README describes a self-hosted, MIT licensed library that mounts into your own server as an http.Handler.

It covers sign-in for people: passwords, magic links, social login, passkeys, TOTP, SAML SSO and SCIM. It also covers sign-in for software: an OAuth 2.1 authorization server with PKCE (RFC 7636), DPoP (RFC 9449) and token exchange, plus a resource server module for MCP.

The code below shortens the README quick start. The real one also sets up the SQLite database and runs the migration before theauth.New, and it hard codes a localhost base URL where I read an environment variable.

a, err := theauth.New(theauth.Config{CoreStorage: store, BaseURL: os.Getenv("BASE_URL")})
if err != nil {
    log.Fatal(err)
}
defer a.Close()

mux := http.NewServeMux()
mux.Handle("/auth/", a.Handler()) // sign-up, sign-in, magic link, sessions
mux.Handle("GET /me", a.RequireAuth()(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    user, _ := theauth.UserFromContext(r.Context())
    w.Write([]byte("hello " + user.Email))
})))

Storage options are memory, SQLite, Postgres and MySQL, and feature support differs per backend. Releases carry cosign signatures, an SBOM and build provenance attestations (the README badge says SLSA 3). Levelrail, another project I maintain, imports it in production code.

Pick it if you want sign-in and an OAuth server in one module, or you need MCP authorization from Go. Otherwise, read the next section.

What theauth-go does not do

I would rather you hear this from me.

The library is young. The repo's first commit was in June 2026, and six stars suggests few people outside my own projects have run it. It has had far less outside use than libraries that date from 2014 and 2015.

I have no head to head benchmark against anyone, so I make no speed claims. The one performance number I trust is narrow. A session lookup as one joined query took 30 microseconds against 58 to 67 for two queries, on one Apple M4 Max, using BenchmarkSessionLookup. That compares two designs inside my own code and says nothing about other libraries.

It also doesn't replace a standalone identity server. Casdoor, Zitadel and Authelia run as separate servers. If you want that shape, you are shopping in a different aisle (the next article in this series maps it).

Finally, breadth has a cost. One library doing sign-in, OAuth server and SCIM means more surface for me to maintain than fosite's single job. If you need only one slice, the focused library is the safer pick. That means fosite for an OAuth server, go-webauthn for passkeys and goth for social login.

How do I choose between these Go auth libraries?

If your job is	Look at first
Issue OAuth2 or OIDC tokens, bring your own users	fosite
Email and password flows on a server rendered site	authboss
Only "Sign in with X"	goth
Add passkeys to an existing system	go-webauthn
Sign-in plus OAuth 2.1 plus MCP in one embedded module	theauth-go, with the age caveat above

Frequently asked

Which of these Go auth libraries handles passwords and email confirmation?

Authboss. It covers sign-up, email confirmation and password recovery for server-rendered sites. Goth and go-webauthn don't manage passwords.

Can I use fosite as a sign-in library?

No. Fosite issues tokens as an OAuth2 and OpenID Connect server and leaves users, storage and login screens to you.

Is theauth-go ready to replace the older libraries?

Not on age. For a single job like passkeys or social login, the focused library is the safer pick.

The bottom line

None of these is "the" Go auth library. The question hides five questions. Decide which side of the wire you are on, how much of the user lifecycle you want to own, and how much age you need in your dependency. Then read the README of the one that fits and try its example before you believe me or anyone else.

Which job was yours, and did one of these fit? I would like to hear where the gaps are.

If you want to read the code or try it, the repo is here:

glincker / theauth-go

Self-hosted Go authentication library. Embeds in net/http, chi, Gin, Echo or Fiber. OAuth 2.1 authorization server, MCP authorization (RFC 9728), passkeys, SAML, SCIM, TOTP, magic links, DPoP. SQLite, Postgres or MySQL. MIT, no hosted service.

theauth-go

OAuth 2.1 and sign-in for Go MCP servers and agents. It mounts into your own net/http server, your users and tokens stay in your own database, and there is no hosted service. MIT licensed.

Who it is for: Go developers building MCP servers, agent backends or internal tools who want to own their auth instead of renting it.

What you…

View on GitHub

GDS K S · thegdsks.com · building Glincker · follow on X @thegdsks

Picking an auth library means picking which job you refuse to write yourself.

Go auth libraries: pick by the side of the wire you are on

GDS K S — Sat, 31 Oct 2026 05:21:46 +0000

Go auth libraries: pick by the side of the wire you are on

Which side of the wire are you on? Are you calling someone else's API, checking a token someone else issued, or issuing tokens yourself? Go auth libraries cluster by that answer, and OAuth threads go wrong when people skip it. This article sorts the main libraries into four groups and ends with a decision flow you can follow in a minute.

I maintain theauth-go, a four month old library with 6 GitHub stars, so weigh my opinions accordingly. The article is not really about it.

Repo: glincker/theauth-go (MIT licensed Go library). Docs: docs.theauth.dev/go.

Which Go auth library should I use?

Someone asks "which auth library should I use" and gets answers that solve three different problems. Name your side first, then the shortlist gets short.

Stats are from the GitHub API on 2026-10-30.

Side of the wire	You are...	Look at	Stars
Client	Calling an API with OAuth credentials	golang/oauth2, grokify/goauth	5,908 and 74
Verifier	Checking tokens or ID tokens from a provider	coreos/go-oidc	2,503
Embeddable server	Issuing tokens or signing in users inside your own process	fosite, theauth-go, others	2,631 and 6
Standalone server	Running identity as a separate service	Hydra, Dex, Zitadel	17,639, 11,227, 15,484

Which Go library calls an OAuth API for me?

If your Go program needs a token to call GitHub, Google or a SaaS API, you are a client. The anchor is golang/oauth2 (pkg.go.dev docs). Its README calls it a client implementation of the OAuth 2.0 spec, defined in RFC 6749. The repo has 5,908 stars, dates from 2014-04, was last pushed 2026-09-08 and uses a BSD-3 license.

On top of that sits a layer of convenience. grokify/goauth is the one I want to say something kind about. The project is small (74 stars, from 2017-06, last pushed 2026-10-30, MIT) and does real work. Its README describes a way to create authenticated *http.Client instances from a single JSON configuration file, with pre-configured endpoints for 40+ OAuth 2.0 providers. It lists six grant types, PKCE (RFC 7636) and DPoP (RFC 9449) support, and command line tools for token generation.

That shape helps if you juggle credentials for a dozen SaaS APIs in one program and want one config format. Its last push was the day of my snapshot. If your problem is "I call twelve vendor APIs", look at goauth before you write your own token plumbing.

None of this is a server. These libraries exist so your program can get and use tokens, not issue them.

Note: sign-in with social providers sits on the border. Goth (markbates/goth, 6,620 stars) is a client side library for "Sign in with X" in a web app. It consumes other providers. It is not a server you run for others.

How do I verify OIDC ID tokens in Go?

If a provider issued the token and your service only needs to trust it, you are a verifier. The library is coreos/go-oidc (pkg.go.dev docs). Its README describes an OpenID Connect client that works with golang.org/x/oauth2. The quick start creates a provider by discovery, then an ID token verifier:

provider, err := oidc.NewProvider(ctx, "https://accounts.google.com")
// ...
idTokenVerifier := provider.Verifier(&oidc.Config{ClientID: clientID})

The README snippet is cut short here. The full version also builds the oauth2.Config. The repo has 2,503 stars, dates from 2015-06, was last pushed 2026-10-19 and uses Apache-2.0. Its README says over 1000 open source projects import it. The ID token format itself comes from the OpenID Connect Core spec.

Choose this when your service sits behind an identity provider (Google, Okta, a Kubernetes cluster) and the work is checking signatures, issuer and audience. You do not need an auth server for that. Adding one means extra moving parts for no gain.

Which Go library lets me run my own OAuth server?

Now you are the provider. Users sign in to you, or other apps ask you for tokens. Embeddable means the code runs in your binary, mounts on your router, and uses your database.

The long standing option for the protocol half is fosite (2,631 stars, from 2015-12, last push 2025-11-20, Apache-2.0). Its README describes an OAuth2 and OpenID Connect framework. Fosite is a toolkit, so storage and user handling are yours.

For web sign-in flows there is authboss (4,201 stars). For passkeys alone there is go-webauthn (1,357 stars).

Then there is theauth-go, which tries to put sign-in, an OAuth 2.1 server and MCP authorization behind one http.Handler. Here is the sign-in half, shortened from its README quick start (I left out the database setup, and the README hard codes a localhost base URL where I read an environment variable):

a, err := theauth.New(theauth.Config{CoreStorage: store, BaseURL: os.Getenv("BASE_URL")})
if err != nil {
    log.Fatal(err)
}
defer a.Close()

mux := http.NewServeMux()
mux.Handle("/auth/", a.Handler())

The honest comparison: fosite has a decade of use and one focused job. Theauth-go has months of use and a wide job. If you only need the OAuth server half, read fosite's README first. If you want the pieces pre-assembled and can accept a young dependency, mine is worth a trial in a sandbox.

When should I run a standalone auth server?

Sometimes the right answer is not a library. You run a service, and your Go apps talk to it over HTTP. These stats come from the same 2026-10-30 snapshot. I copied the shape column from my own research notes and did not recheck it against each README.

Project	Stars	License	Shape
ory/hydra	17,639	Apache-2.0	OAuth2 and OIDC provider, separate service
dexidp/dex	11,227	Apache-2.0	OIDC federation
zitadel/zitadel	15,484	AGPL-3.0	Full identity platform

Pick this side when a mix of languages shares one identity system, when a team other than yours operates it, or when you want a project with that kind of adoption behind it. Zitadel is AGPL-3.0, which matters to some companies and not to others, so read it before you plan around it. Any standalone server is one more thing to deploy, upgrade and keep available.

A decision flow for choosing a Go auth library

Are you calling an API with your own credentials?
  yes -> client side: golang/oauth2, or grokify/goauth for multiple vendors
  no  -> continue

Did another party issue the token you need to check?
  yes -> verifier: coreos/go-oidc
  no  -> continue

Do you need to issue tokens or sign users in?
  yes -> Must it run as its own service, or serve a mix of languages?
           yes -> standalone server: Hydra, Dex, Zitadel
           no  -> embeddable: fosite (protocol only), authboss (web flows),
                  go-webauthn (passkeys only), or theauth-go (all in one, young)

Real systems hit more than one box. A service can verify tokens with go-oidc at the edge, call vendors through oauth2 behind it, and embed a server for its own users. Use the flow to pick a starting library per job, not one answer for the whole app.

Where the lines blur

Two places trip people up. First, goth and goauth both help with "Sign in with Google", but goth targets web app login while goauth centers on authenticated API clients. Check which one matches your flow.

Second, an embeddable server often includes a verifier. If you run your own authorization server and also host an API, your API still has to check tokens. In theauth-go that is a separate zero dependency module called mcpresource, so a resource server skips the whole library.

Frequently asked

Do I need an auth server to verify tokens from Google or Okta?

No. A provider already issued the token, so you are a verifier. go-oidc checks signature, issuer and audience, and you run no server of your own.

Which Go library is for calling several vendor APIs?

Start with golang/oauth2. If you juggle credentials for several providers, goauth offers one JSON config and pre-configured endpoints for 40+ OAuth 2.0 providers.

Is a library or a standalone server better?

It depends on who operates it. A standalone server suits mixed languages or a separate team. A library keeps everything in one binary, with fewer services to run.

The bottom line

Before you compare feature tables, name your side of the wire. Calling an API points you to oauth2 or goauth. Trusting a provider points you to go-oidc. Issuing tokens points you to fosite, authboss, go-webauthn, a standalone server, or an all in one like mine. Star counts tell you how many people have looked. They say nothing about fit, so read the README and run the example.

If your case falls between two of these boxes, which one and why? That is the part I want to hear about.

If you want to read the code or try it, the repo is here:

glincker / theauth-go

Self-hosted Go authentication library. Embeds in net/http, chi, Gin, Echo or Fiber. OAuth 2.1 authorization server, MCP authorization (RFC 9728), passkeys, SAML, SCIM, TOTP, magic links, DPoP. SQLite, Postgres or MySQL. MIT, no hosted service.

theauth-go

OAuth 2.1 and sign-in for Go MCP servers and agents. It mounts into your own net/http server, your users and tokens stay in your own database, and there is no hosted service. MIT licensed.

Who it is for: Go developers building MCP servers, agent backends or internal tools who want to own their auth instead of renting it.

What you…

View on GitHub

GDS K S · thegdsks.com · building Glincker · follow on X @thegdsks

The right Go auth library is whichever one matches the side of the wire you actually stand on.

Self-Hosted Vercel and Heroku Alternatives, Compared

GDS K S — Fri, 30 Oct 2026 22:23:44 +0000

Levelrail is open source (Apache 2.0). Read the code, star it and try it on GitHub: github.com/glincker/levelrail, or install it in one command.

Searching for a self-hosted Vercel alternative turns up a long list, and the names do different things. Some copy the Heroku git push workflow. Some are dashboards over Docker. Some also want you to run a cluster. This post sorts them out, says what each is good at, and ends with a pick by use case.

I build Levelrail, so I put it first in the picks and say why. The rest are worth your time too, and I have kept the claims about them to what their own repositories and docs say. For a per-feature view, the Coolify comparison has sources for each row, and the alternatives page covers the wider field.

The hosted options first

You may not need to self-host. Here is what the hosted platforms do.

Vercel deploys from GitHub, GitLab or Bitbucket, and every push to the connected branch triggers a new deployment. It has a CLI and lets you provision databases from its marketplace. Its design centers on front-end frameworks and its own functions runtime.

Heroku is where git push heroku main came from. You push to a remote, it builds, and it creates a new release. Its docs list limits worth knowing, such as the app having to sit at the root of the repository.

Railway builds a Docker image from a repository or deploys an image you supply, and gives you a dashboard, volumes with backups and private networking inside a project.

All three run the servers for you, and that is a fair reason to stay. People leave when cost grows with usage, when data location matters, or when they want one machine they control to hold everything.

The self-hosted options

Coolify

Coolify is Apache 2.0 licensed and installs with a single curl command on any server you can reach over SSH. It deploys from GitHub, GitLab, Bitbucket or Gitea with deploy on push and pull request previews, builds with Nixpacks, Railpack, a Dockerfile, Compose or a prebuilt image, and ships over 360 one-click services. It has managed databases, database and storage backups, automatic HTTPS and multi-server management.

Coolify is the most widely known option here and the template catalog is the draw. It fits solo developers and small teams who want a friendly dashboard and lots of ready-made services. If you already run it, the Coolify importer reads your setup without changing it.

Dokploy

Dokploy installs with one curl command on a VPS. It runs PostgreSQL, MySQL, MariaDB, MongoDB, libsql and Redis, takes automated database backups to external storage, uses Traefik for routing and Docker Swarm for multi-node scaling. It shows CPU, memory, storage and network use per resource and can ship logs and metrics to tools such as Grafana.

The repository is Apache 2.0 with a carve-out: content under a /proprietary directory is under a separate license, so read that file before you depend on it. It fits people who already like Swarm and want a dashboard on top of it.

CapRover

CapRover has a web GUI and a CLI, runs on Docker Swarm, uses an Nginx template for load balancing, issues free Let's Encrypt certificates, and installs databases such as MariaDB, MySQL and MongoDB from a dropdown. Its README lists NetData monitoring.

The license is Apache 2.0 with an appendix that restricts changes to its paid features, so read the LICENSE file if you plan to fork. It fits people who want a simple Swarm-based panel for a handful of apps.

Dokku

Dokku is MIT licensed and calls itself a Docker powered mini-Heroku. You install it on a fresh Ubuntu or Debian machine with a bootstrap script, add your SSH key, and deploy with git push dokku main. It builds with Heroku buildpacks by default and also takes a Dockerfile or an image. You drive it with dokku commands on the host, and services such as PostgreSQL arrive as plugins.

The core project has no dashboard, which suits people who live in a terminal. It fits solo developers and homelabs who want the Heroku workflow on one box with the fewest moving parts.

Levelrail

Levelrail is Apache 2.0 and ships as one Go binary that runs your apps in Docker. Levelrail needs no Kubernetes. The install is one command:

curl -fsSL https://levelrail.com/install.sh | sudo sh

Deploys start when you push to GitHub, GitLab, Bitbucket or Gitea, with preview environments per pull request. HTTPS comes from an embedded Caddy ingress, with Let's Encrypt behind one toggle. Databases (Postgres, MySQL, MariaDB, MongoDB, Redis and more) get scheduled backups that the platform verifies automatically. Metrics, logs and alerts come included, so you do not install a monitoring stack next to it. A deploy only cuts traffic over once the new version is ready, and a bad release rolls back to the previous image with one command. There is also an MCP server, so an AI assistant can inspect and operate the platform.

The tradeoff: the community is smaller than Coolify's or Dokku's, so there are fewer third party guides to lean on. Pick it if you care more about what happens after the deploy (rollback, backups you can trust, alerts) than about the size of the catalog.

Facts side by side

	License	Install	Dashboard	Databases and backups
Coolify	Apache 2.0	`curl` script	Yes	Managed databases, backups
Dokploy	Apache 2.0, with a proprietary directory	`curl` script	Yes	Six engines, backups to external storage
CapRover	Apache 2.0, with a paid-features appendix	Setup per its guide	Yes, plus a CLI	Installed from a dropdown
Dokku	MIT	Bootstrap script	Core is CLI only	Via plugins
Levelrail	Apache 2.0	`curl` script	Yes	Scheduled, automatically verified backups

Sources are each project's GitHub repository and docs, read on 2026-10-30. Where a project's page did not state something, I left it out rather than guess.

Which should you pick

A solo developer leaving Vercel or Heroku to run real apps with a database should start with Levelrail. One command installs it, a push deploys, and logs, metrics, alerts and rollback are there on day one without extra setup. If you only want the Heroku flow on one box and like the terminal, Dokku is lighter.

A small team or agency with client apps should also look at Levelrail first, for the backups and rollback that matter more as clients multiply. Coolify is a strong second if the one-click catalog is what saves you time.

For a homelab, Dokku suits shell people, and Coolify suits anyone who wants a dashboard and a big catalog of services to try. Levelrail runs on a small machine too and gives you metrics without extra containers.

If you already run Swarm, Dokploy and CapRover are both built on it, so they fit what you know.

If you need a global edge network for a front end, keep Vercel for that site. A single server will not replace it, and mixing the two is fine.

Weighing Levelrail against Coolify specifically? Read the Coolify comparison. For the Heroku side, see Heroku alternatives you can self-host. To try it, follow the five-minute install or the install page, and the docs cover the rest.

FAQ

What is the best self-hosted alternative to Vercel?

It depends on what you deploy. For a front end with preview deployments, Coolify and Levelrail both build from a Git repository and deploy on push. For a mix of front ends, APIs and databases on one server, with logs, metrics and rollback built in, Levelrail is the one this site recommends. You will not match Vercel's global edge network on a single server, so decide whether you need that.

What is the best self-hosted alternative to Heroku?

Dokku is the closest to the Heroku workflow: git push to a remote, Heroku buildpacks by default, and Dockerfile or image deploys too. If you want a web dashboard, health checks and rollback on top of that workflow, look at Levelrail or Coolify.

Can I run a self-hosted platform on a cheap VPS?

Levelrail boots on 1 vCPU, 1 GB of RAM and 10 GB of disk, and 2 vCPU with 2 GB is more comfortable once you build images on the same box. For the others, check each project's installation guide for its stated requirements, since they are not all listed on the repository pages.

Is it worth leaving Vercel or Heroku for a self-hosted platform?

If your bill is small and you value not running servers, stay. Moving makes sense when the bill grows with traffic or seats, when data must stay on hardware you control, or when you already pay for a server that has spare room. You take on updates, backups and uptime, so pick a platform that automates those.

Originally published at levelrail.com/blog/self-hosted-vercel-heroku-alternatives.

5 Self-Hosted Apps Worth Running on Your Own Server

GDS K S — Fri, 30 Oct 2026 22:23:31 +0000

Levelrail runs all five on one server with HTTPS, backups and rollback. It is open source (Apache 2.0): star it on GitHub or install it in one command.

Most "best self hosted apps" lists are a wall of 80 logos. This one has five, picked because each replaces a hosted tool people pay for every month, and each one is small enough to run on a single cheap server.

Every app below is a one-click template in Levelrail, a self-hosted platform that deploys apps to your own Linux server from a git push or a template. Each section ends with the install command.

Run them on one server, not five

The hard part of self-hosting is not the first install. The fifth is harder, when you have five apps, five upgrade schedules and no idea which volume holds what.

Levelrail gives you one place for that: HTTPS on your own domains, logs per app, deploy history with rollback, and backups of app volumes to an S3-compatible bucket. If you have not installed it yet, the install guide takes minutes, and the five-minute walkthrough shows the real output.

The template catalog lists the templates. A smoke run on 2026-10-25 brought up the five below, and every one passed. If you already run another platform, the comparison with Coolify lists the differences with sources.

1. Uptime Kuma: know before your users do

Screenshot: Uptime Kuma dashboard, from the project README (MIT license). Source: github.com/louislam/uptime-kuma

It replaces hosted uptime monitoring subscriptions.

Uptime Kuma checks HTTP, TCP, DNS and ping targets on a schedule and shows a dashboard. It suits anyone with more than one site or service who currently finds out about outages from a customer.

A concrete use: add every app you host here, plus the ones you do not. Put Uptime Kuma on the same server as the apps and you will learn what breaks the setup: if the server dies, the checks die with it. Point a second check at it from somewhere else.

Watch out for:

Memory is small. The template recommends 256 MB.
Back up the data volume, which holds the SQLite database and uploads.
Upgrades matter. The template pins the 1.23 line. Version 2 migrates the database to a layout you cannot roll back, so back up first and upgrade on purpose.

Install it. This template ships with an install form, so you can set a domain in the same command:

levelrail-cli templates install uptime-kuma --domain kuma=status.example.com

2. Umami: analytics without a cookie banner

The Umami logo, shown only to identify the project. Visit umami.is for screenshots.

It replaces a paid analytics subscription for small sites.

Umami counts visits, pages and referrers without tracking cookies. It suits people who want to know which post got read, not to profile anyone.

A concrete use: one Umami instance can hold every site you run. Paste one script tag per site and you have a single dashboard instead of one login per project.

Watch out for:

It runs with a Postgres container next to it. The template recommends 512 MB for the app.
Back up umami_db_data. That volume is your whole history.
Migrations run on boot and only go forward. Keep the postgresql- variant of the image tag and upgrade one release at a time.

Install it:

levelrail-cli templates deploy umami

3. n8n: automation you can see

The n8n logo, shown only to identify the project. n8n is under the Sustainable Use License, so we link instead of copying its screenshots: n8n.io.

It replaces hosted workflow automation with per-task pricing.

n8n is a visual editor where you connect services with nodes. It suits people who keep writing small scripts to move data between tools and would rather draw it.

A concrete use: a workflow that watches a form, writes the row to a sheet and posts to chat. You can run the same flow a thousand times without watching a task counter.

Watch out for:

The template recommends 512 MB.
Back up n8n_data. It holds the database and the encryption key. If you lose the key, every saved credential becomes unreadable.
Read the release notes before changing the image tag, because nodes get removed between versions.
The default template stores data in a SQLite file. For heavier workflow volumes there is an n8n-postgres template.

Install it:

levelrail-cli templates deploy n8n

4. Vaultwarden: a password manager you host

The Vaultwarden logo, shown only to identify the project. Vaultwarden is AGPL-3.0, so we link instead of copying screenshots: github.com/dani-garcia/vaultwarden.

It replaces a hosted password manager subscription.

Vaultwarden is a small server that works with the Bitwarden clients, so you keep the browser extension and phone apps and move only the server. It suits individuals and families who want the vault on hardware they control.

A concrete use: a shared family vault for the streaming logins and the router password, behind your own domain.

This is the one app on the list where a mistake costs the most, so be strict:

Serve it over HTTPS only. The clients expect it.
Back up vaultwarden_data, which holds the database, attachments and keys, and keep a copy offline.
Tag bumps are safe and frequent, since the web vault has to match the server. Do not let it fall far behind.
The template recommends 256 MB, the lowest of the five.

Install it:

levelrail-cli templates deploy vaultwarden

5. Gitea: your own git server

Screenshot: Gitea home page, from the project README (MIT license). Source: github.com/go-gitea/gitea

It replaces a hosted git service for private repositories.

Gitea is a light git host with issues, pull requests and a package registry. It is for solo developers and small teams who want private code on their own disk, or a place to mirror what lives elsewhere.

A concrete use: keep client work or infrastructure repos here, and connect it to Levelrail as a git provider so a push deploys the app. Levelrail lists Gitea next to GitHub, GitLab and Bitbucket in its git integrations.

Watch out for:

The default template runs Gitea with a MariaDB container and recommends 512 MB. If you prefer one database engine everywhere, use gitea-postgres.
Back up both gitea_db_data and gitea_data. The repositories live in the second one.
Gitea migrates its database on boot and does not support downgrades. Move one minor version at a time and read the breaking changes first.

Install it:

levelrail-cli templates deploy gitea

The template publishes the git port as 2222 by default, so open it in your firewall only if you want SSH clones.

What all five need from you

The apps differ, but the chores are the same. Pick a backup target before you store anything you care about, and test a restore once. The docs on backups and storage cover app volume backups, and every section above names the volume to protect.

Upgrade on purpose, one version at a time, with a backup taken first. And keep a rollback in mind: this walkthrough shows how a bad release gets undone.

On sizing, the five templates recommend 2 GB of memory in total. A 4 GB server runs them with room left for the platform. Browse the templates page if you want more than five.

FAQ

What should I self-host first?

Start with something small that you will notice if it breaks, like an uptime monitor. Uptime Kuma is a good first pick: its template recommends 256 MB of memory and it keeps everything in one data volume. Move on to a password manager or analytics once you trust your backups.

How much server do I need to self-host these apps?

The memory recommended by the five templates adds up to 2 GB: 256 MB each for Uptime Kuma and Vaultwarden, 512 MB each for Umami, n8n and Gitea. Add room for the platform itself, which boots on 1 GB of RAM, so a 4 GB server is a comfortable size for all five.

Is self-hosting a password manager safe?

It is safe only if you keep it patched, serve it over HTTPS and back up its data volume somewhere other than the same server. Vaultwarden stores its database, attachments and keys in one volume. Keep an offline copy of that backup.

Do I need Docker knowledge to self-host these?

Not to get them running. Each app is a ready-made template with its image, database and volumes defined, so you install it from the dashboard or one CLI command. You will want to understand volumes and backups before you trust it with real data.

Originally published at levelrail.com/blog/best-self-hosted-apps-worth-running.