glincker

🚀 Trending on GitHub awesome-selfhosted-ai by glincker ⭐ 78 🧠 A living, auto-updated list of 308 free AI tools you can run on your own hardware, from local chatbots to RAG and image generation. glincker/awesome-selfhosted-ai #GenAI #OpenSource #AI

Zero Downtime Deploy for Docker Apps, With Rollback 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.

Small project, practical idea: awesome-selfhosted-ai installs a personal Android agent that operates shell, browser, MCP, and phone apps. Try it: git clone glincker/awesome-selfhosted-ai glincker/awesome-selfhosted-ai

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. The idea: the list is generated from one JSON file, and a weekly job checks each repo against the GitHub API. Archived, deleted, or year-silent projects move to a separate file automatically, and return if they become active. There is a live table with stars, last push and license, and a section for source-available tools so the license terms are visible. I used AI tools to help find candidates and draft descriptions; the script verifies each entry. Happy to hear what is missing or mislabeled. glincker/awesome-selfhosted-ai

I made a self-hosted AI list that checks every project weekly and moves dead ones out Self-hosting AI feels fragmented, and most lists go stale. I built one that re-checks itself. - 278 projects in 16 categories (runtimes, chat UIs, RAG, MCP, voice, OCR, home AI and more) - A weekly job reads each repo through the GitHub API: archived, deleted, or silent for a year moves to a separate Unmaintained file - A live table with stars, last push, license and a colored status - Popular tools with restrictive licenses are in their own section, license shown I maintain it. AI tools helped me find candidates and draft descriptions; a script verifies each entry. Tell me what is missing or wrong. glincker/awesome-selfhosted-ai

I built a self-hosted AI list that checks itself weekly 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. {% embed glincker/awesome-selfhosted-ai %} 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: glincker/awesome-selfhosted-ai What is missing? Tell me which project should be in it.

Introducing Levelrail: an open source deployment platform you run on your own server. No memberships, and the features you wished other platforms had

J'ai bookmarqué ça, mais pas encore eu le temps de regarder si c'était sérieux ou pas glincker/levelrail

sslx - openssl, but you don't have to google the flags Rust written CLI tool to simplfy grade, verify or inspect certs as well as creating them. glincker/sslx

sslx 是一个用 Rust 编写的开源命令行工具，把查看证书、检测 TLS 连接、生成和转换证书这些原本要背一堆复杂参数的 OpenSSL 操作，压缩成一个二进制文件里的简单命令——正如它的自我介绍：“openssl，但你不需要去谷歌搜索参数”。 glincker/sslx t.co