标签：#selfhosted

Downloading an installer and immediately executing it as root collapses three operational decisions into one command: Which artifact? -> Did these bytes arrive intact? -> Should this host execute them? Separate those decisions and the install becomes reviewable, reproducible, and recoverable. A concrete source-review boundary At commit c58bcd4 , the MonkeyCode runner installation template selects x86_64 or aarch64 , checks AVX on x86, requires root, and downloads an architecture-specific installer before executing it. The reviewed template uses curl -4sSLk , so certificate verification is disabled by -k . It also downloads an unversioned path. I could not find a pinned version, digest, or signature check in that template. That is a statement about controls visible in one pinned file—not a claim that the release service is compromised or that no external release control exists. Put a manifest before execution For each release artifact, publish immutable metadata through a separately protected release process: { "version" : "1.2.3" , "architecture" : "x86_64" , "file" : "runner-installer-1.2.3-x86_64" , "sha256" : "<64 lowercase hex characters>" , "size" : 18439210 , "rollback" : { "previous_version" : "1.2.2" , "artifact" : "runner-installer-1.2.2-x86_64" } } SHA-256 detects bytes that differ from the manifest. It does not prove who authored the manifest. Serve the manifest over validated TLS, pin it through deployment configuration, or sign it and verify the signature with a trusted offline public key. Verify as an unprivileged staging step The companion verify-installer.mjs checks filename, exact size, digest, version, architecture, and rollback metadata: node verify-installer.mjs release-manifest.json fixture-installer.sh node test-verifier.mjs Expected output uses the fixture's actual digest: PASS 1.2.3-fixture sha256=<digest> PASS verified fixture; rejected tampered artifact before execution The negative test appends a line to the artifact and requires both size

The failures that cost me the most in three years of self-hosting were never the ones that threw an error. An error is a gift: it tells you where to look. The expensive ones are the failures that report success while being broken . A page that returns 200 OK . A healthcheck that says the container is fine. A backup that exits cleanly. A command that prints nothing wrong. Everything green, everything lying. Here are four of them, all from the same box (a 2016 desktop, i7-6700 / 32 GB, Docker behind Caddy, reachable only over Tailscale). Each fails by handing you a success signal. Each cost me an evening the first time. The fixes are boring once you know them, the point is knowing the failure exists. Sanitized skeleton with all the config at the end. 1. A loading page that returns 200 This one I could find nothing written about, so it cost me the most. To keep the box quiet, I run the heavy services on-demand: Sablier stops idle containers and starts them on the first request. Caddy (with the Sablier plugin) gates a virtual host behind a container group, serves a "please wait, starting up" page while the group boots, then proxies through: myhost . my - tailnet . ts . net : 8081 { route { sablier http :// sablier : 10000 { group office session_duration 30 m } reverse_proxy nextcloud : 80 } } I gate my whole Nextcloud vhost, WebDAV included, this way. And here is the silent failure: if the gated group is not healthy, Sablier serves that HTML loading page for every request, and it serves it with 200 OK . A browser shows a spinner, fine. But my Obsidian vault syncs over WebDAV, and a WebDAV client asking for a directory listing got a 200 with a chunk of HTML instead of the XML it expected. Sync died with a cryptic no root multistatus found . Nextcloud itself was up and perfectly healthy the whole time. Every uptime check I had was green, because the gate in front kept answering 200 . The structural lesson: the moment you put a service on-demand behind a reverse proxy, tha

Most agent demos are one-shot loops. You open a terminal, give the model a task, watch it call tools, and then the process dies. That is fine for coding sessions. It is a weak shape for an assistant that is meant to live in your actual workflow. Talon is built around the other shape: a persistent agent process with frontends, memory, tools, background jobs, and swappable model backends. What it runs on Talon can expose the same agent core through: Telegram Discord Microsoft Teams terminal chat a desktop/mobile companion bridge That means the agent is not tied to one UI. The chat app is just a mouth. The core state, tools, memory, goals, and model backend live behind it. Backends are swappable The same harness can run through: Claude Agent SDK OpenAI Agents Codex Kilo OpenCode Each backend implements the same capability interface, so the rest of the system does not need to care which model runtime is active. It has real operating machinery The important parts are not flashy. They are the things that let an agent keep working after the first message: MCP plugins for tools cron jobs for scheduled actions triggers for condition-based wakeups persistent goals for multi-session work long-term memory heartbeat mode for background progress dream mode for consolidation per-chat model and effort settings This is the difference between "chat with a model" and "run an assistant". Install npm install -g talon-agent talon setup talon start Repo: https://github.com/dylanneve1/talon If this is the kind of agent infrastructure you want more of, a GitHub star helps the project get found.

Azure Storage SFTP is Microsoft's managed file transfer service on top of Azure Blob Storage, convenient, but billed continuously per endpoint (roughly $0.30/hour, ~$220/month) and tied to Azure AD. SFTPGo is an open-source file transfer server offering SFTP, FTP/S, and WebDAV with pluggable storage backends (local disk, Azure Blob, S3-compatible, GCS) and no per-endpoint charge. This guide deploys SFTPGo with Docker Compose and Traefik, sets up user auth (password + SSH key + 2FA), connects S3-compatible object storage, and covers the migration path from Azure Storage SFTP. By the end, you'll have a self-hosted file transfer server with the same capabilities at zero endpoint cost. Azure Storage SFTP → SFTPGo Mapping Azure Storage SFTP SFTPGo Equivalent Notes SFTP Endpoint SFTPGo SFTP Server Configurable port, default 2022 Azure Blob Storage Azure Blob backend Native support; point at the same container, no migration needed Azure AD Authentication LDAP/OIDC plugin External identity provider via plugin Local Users Web UI / REST API user management Hierarchical Namespace Virtual directories No HNS requirement Azure Monitor Built-in logging + webhooks/syslog Prerequisite: Linux server with Docker + Compose, a DNS A record for your domain, and (if migrating) an existing Azure Storage account with SFTP enabled plus the Azure CLI installed locally. Deploy with Docker Compose 1. Create the project directories: $ mkdir -p ~/sftpgo/ { data,config } $ cd ~/sftpgo 2. Create the environment file: $ nano .env DOMAIN = sftp.example.com LETSENCRYPT_EMAIL = admin@example.com 3. Create the Compose manifest: $ nano docker-compose.yml services : traefik : image : traefik:v3.6 container_name : traefik command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirections.entrypoint.to=websecure" - " --certificatesresolvers.letsencrypt.acme.httpchallenge=tr

One-Command Deployment: Self-Host Your AI Wallet with Docker and GHCR Would you trust a third party with your AI agent's private keys? If that question makes you uncomfortable, you're already thinking about self-hosting your wallet infrastructure — and WAIaaS makes it genuinely practical with a single Docker command. This post walks through how to get a fully self-hosted Wallet-as-a-Service running on your own server, with your own keys, under your own rules. Why Self-Hosting Your AI Wallet Actually Matters The rise of autonomous AI agents changes the stakes around custody. When a human manages a wallet, they can pause, verify, and think before signing. An AI agent operates continuously, potentially making hundreds of transactions — so the infrastructure holding those keys becomes critically important. Hosted wallet services make a trade-off: you get convenience in exchange for trusting someone else's server, someone else's rate limits, and someone else's uptime SLA. For many teams building experimental agents, that's fine. But for anyone running production workloads, handling real funds, or operating in environments with strict data residency requirements, the calculus shifts. Self-hosting gives you: Full key custody — private keys never leave your infrastructure No rate limits imposed by a third party — your server, your throughput Auditability — WAIaaS is open-source, so you can read every line of code handling your keys Network control — bind to localhost, put it behind a VPN, restrict egress however you want WAIaaS is built specifically for this use case: a self-hosted, open-source Wallet-as-a-Service designed for AI agents, deployable in one command. The One-Command Start The Docker image is published to GitHub Container Registry (GHCR) at ghcr.io/minhoyoo-iotrust/waiaas:latest . The fastest path to a running instance is: git clone https://github.com/minhoyoo-iotrust/WAIaaS.git cd WAIaaS docker compose up -d That's it. The daemon starts on port 3100 , bound to

I have a folder on my laptop called side-projects . Most of them are Dockerized. Most of them will never see more than a handful of users. And for years, every one of them hit the same wall: getting the thing onto a cheap VPS without losing a weekend — and copy-pasting my own past mistakes forward every single time. Here's the opinion that eventually turned into a project: the part of a PaaS you touch most often should hold the least power over your server. Think of a deploy tool as two planes. There's a read plane — dashboards, logs, container health, the stuff you stare at — where you spend most of your time and which is your most exposed surface. And there's a write plane — deploy, restart, the actions that actually change the system — which is rare and should be gated. My frustration was that the thing I looked at all day and the thing that could rewrite my box tended to sit on the same pile of privilege. So I built Mooring to keep those two planes apart. It's an early, solo project, and this post is me showing it and asking for eyes on it. The mental model The whole thing, end to end: Install it as an unprivileged systemd service (not root). Connect a git repo. Write one mooring.yaml . Click Deploy. That's the loop. Everything below is what's underneath it. What it is Mooring is a small, security-first, self-hosted control plane for Docker — a tiny PaaS. You point it at a git repo, describe your app once, and it deploys and runs your containers on your own server. Same territory as Coolify, Dokku, CapRover, and Kamal — all genuinely good work. The difference I care about is the posture underneath. It ships as one static, CGO-free Go binary . It runs as an unprivileged systemd service — not root. State lives in SQLite (the pure-Go modernc driver). Every asset is embedded with go:embed , so there's no node_modules , no asset pipeline, nothing to build on the box. To be honest about the neighborhood: setting up a self-hosted PaaS, these tools tend to want broad ac

The homelab started flat. One /24, everything on it. My workstation, the NAS, the Proxmox host, and — over time — a growing list of workloads sharing the same broadcast domain because that was the path of least resistance. For a while, that was fine. A homelab running one workload doesn't need segmentation any more than a house needs an office door. Then I stood up an Akash provider. An Akash provider is, in shape, a Kubernetes cluster that accepts inbound tenant workloads from the internet — real deployments, paying for compute, containers I didn't write landing in namespaces on my hardware. The provider itself is documented at github.com/jjozzietech/akash-provider-ops-public — this piece is about the network underneath it. The containerisation posture itself is fine. I trust the isolation model. But trust isn't a network design. And the network at that moment had the tenant workload cluster sitting on the same subnet as my workstation, my NAS, and my Proxmox management interface. That was the moment I stopped thinking of the rack as a home network with extra boxes, and started thinking of it as a small data centre. This piece is the network design that came out of that shift. I'll cover the layout, the rules that hold it together, and the Nexus and Proxmox configs that anchor it — with the specifics of my own deployment sanitised. It's not a step-by-step replication guide. It's the design pattern, with enough of the shape to be useful and enough restraint to not double as a recon document for my own rack. // the original design The flat layout looked like this: home lan — 192.168.1.0/24 opnsense (perimeter) cisco nexus (dumb L2 switching) proxmox host workload VMs (all on the same subnet) What it got right: zero routing complexity, everything reachable from everywhere, fast to stand up. If you're running one project on a homelab, this is the correct design. Don't over-engineer it. What stopped working, as soon as the second project landed on the rack, was that the

Google's NotebookLM is great. But handing your research notes, PDFs, and meeting transcripts to Google's cloud is a hard sell for a lot of people — especially when those documents contain client data, unpublished research, or internal strategy. So I spent a weekend testing five open-source alternatives. Three things mattered: can I docker compose up in under 10 minutes, does the podcast feature actually work offline, and what breaks first? Here's what I found. The Contenders Project Deploy Time Min VRAM True Offline License Open Notebook (lfnovo) ~8 min 8 GB Yes MIT Notex (smallnest) ~3 min 4 GB Yes Open source KnowNote (MrSibe) ~2 min 4 GB Yes Open source NotebookLM-Local (nagaforcloud) ~15 min 8 GB Qwen-3 4B bundled Open source InsightsLM (phsphd) ~30 min 8 GB Yes N8N SUS license 1. Open Notebook — The One to Beat git clone https://github.com/lfnovo/open-notebook cd open-notebook docker compose up -d Eight minutes from git clone to the web UI on localhost:3000 . It ships with 18+ model providers pre-configured — Ollama, OpenAI, Claude, DeepSeek, Gemini, all selectable per notebook. The podcast generator supports 1-4 speakers with different voices, and it runs entirely offline when you point it at an Ollama backend. What works: Document ingestion is fast — SurrealDB's vector + full-text index handles 200-page PDFs without choking Model switching is genuinely useful — Claude for deep analysis on one notebook, local Qwen for quick summaries on another Podcast quality with 2 speakers is close to NotebookLM's. 4 speakers is still rough. What breaks: Citation highlighting is still being rebuilt (work in progress as of June 2026) Single-user only — no team/workspace isolation built in Docker required. No native binary. 2. Notex — Single Binary, Zero Dependencies Notex is written in Go. You download a single binary (~25MB) and run ./notex . That's it. No Docker, no Python venv, no database setup. It supports PDF, TXT, MD, DOCX, HTML, audio, and YouTube/Bilibili URLs as so

Paperless-ngx is an open-source document management system that converts scans and PDFs into a fully searchable archive using Tesseract OCR, with tags, custom fields, and automated processing rules. This guide deploys Paperless-ngx using Docker Compose with PostgreSQL, Redis, and Traefik handling automatic HTTPS, then uploads a document and verifies OCR extraction. By the end, you'll have Paperless-ngx serving an OCR-indexed document archive securely at your domain. Set Up the Directory Structure 1. Create the project directories: $ mkdir -p ~/paperless-ngx/ { data,media,export,consume,pgdata } $ cd ~/paperless-ngx 2. Create the environment file: $ nano .env DOMAIN = paperless.example.com LETSENCRYPT_EMAIL = admin@example.com PAPERLESS_SECRET_KEY = CHANGE_TO_RANDOM_STRING PAPERLESS_URL = https://paperless.example.com PAPERLESS_TIME_ZONE = UTC PAPERLESS_OCR_LANGUAGE = eng PAPERLESS_DBPASS = STRONG_PASSWORD_HERE POSTGRES_DB = paperless POSTGRES_USER = paperless POSTGRES_PASSWORD = STRONG_PASSWORD_HERE Use the same value for PAPERLESS_DBPASS and POSTGRES_PASSWORD . PAPERLESS_SECRET_KEY should be a 32+ character random string. Deploy with Docker Compose 1. Create the Compose manifest: $ nano docker-compose.yaml services : traefik : image : traefik:v3.6 container_name : traefik command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirections.entrypoint.to=websecure" - " --entrypoints.web.http.redirections.entrypoint.scheme=https" - " --certificatesresolvers.letsencrypt.acme.httpchallenge=true" - " --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - " --certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}" - " --certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports : - " 80:80" - " 443:443" volumes : - " ./letsencrypt:/letsencrypt" - " /var/run/docker.sock:/var/run/docker.sock:ro"

Overleaf is an open-source, collaborative LaTeX editor that bundles MongoDB, Redis, and the ShareLaTeX application into a single self-hosted stack. This guide deploys Overleaf Community Edition using the official Toolkit plus a Traefik override that adds automatic HTTPS via Let's Encrypt. By the end, you'll have Overleaf serving collaborative LaTeX editing securely at your domain. Set Up the Project Directory 1. Clone the Overleaf Toolkit: $ git clone https://github.com/overleaf/toolkit.git ~/overleaf-toolkit $ cd ~/overleaf-toolkit 2. Initialize the configuration: $ bin/init This creates config/overleaf.rc , config/variables.env , and config/version . 3. Create a directory for Traefik file-provider routes: $ mkdir traefik-routes Configure Overleaf for a Reverse Proxy 1. Edit config/variables.env : $ nano config/variables.env OVERLEAF_APP_NAME = "My Overleaf Instance" OVERLEAF_SITE_URL = https://overleaf.example.com OVERLEAF_NAV_TITLE = "Overleaf CE" OVERLEAF_BEHIND_PROXY = true OVERLEAF_SECURE_COOKIE = true The last two flags are required when Overleaf is fronted by an HTTPS reverse proxy. 2. Edit config/overleaf.rc : $ nano config/overleaf.rc SIBLING_CONTAINERS_ENABLED = false 3. Create the project-level .env file used by the Traefik Compose file: $ nano .env DOMAIN = overleaf.example.com LETSENCRYPT_EMAIL = admin@example.com SERVER_IP = 192.0.2.1 SERVER_IP should be the server's public IP (Traefik binds 80/443 to it). Add the Traefik Route 1. Create the dynamic route: $ nano traefik-routes/overleaf.yml http : routers : overleaf : rule : " Host(`overleaf.example.com`)" service : overleaf entryPoints : - websecure tls : certResolver : le services : overleaf : loadBalancer : servers : - url : " http://sharelatex:80" 2. Create the Traefik Compose file: $ nano docker-compose.traefik.yml services : traefik : image : traefik:v3.6 container_name : traefik restart : unless-stopped command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --

NocoDB is an open-source no-code platform that puts a spreadsheet-style UI on top of a relational database, with grid, form, Kanban, and gallery views plus a REST API. This guide deploys NocoDB using Docker Compose with a PostgreSQL backend and Traefik handling automatic HTTPS, then exercises the API with a sample base. By the end, you'll have NocoDB serving a base over HTTPS with API access at your domain. Set Up the Directory Structure 1. Create the project directories: $ mkdir -p ~/nocodb/ { data,pgdata,letsencrypt } $ cd ~/nocodb 2. Create the environment file: $ nano .env DOMAIN = nocodb.example.com LETSENCRYPT_EMAIL = admin@example.com POSTGRES_DB = postgres POSTGRES_PASSWORD = strong_password POSTGRES_USER = postgres Deploy with Docker Compose 1. Create the Compose manifest: $ nano docker-compose.yaml services : traefik : image : traefik:v3.6 container_name : traefik command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirections.entrypoint.to=websecure" - " --entrypoints.web.http.redirections.entrypoint.scheme=https" - " --certificatesresolvers.letsencrypt.acme.httpchallenge=true" - " --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - " --certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}" - " --certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports : - " 80:80" - " 443:443" volumes : - " ./letsencrypt:/letsencrypt" - " /var/run/docker.sock:/var/run/docker.sock:ro" restart : unless-stopped db : image : postgres:16 container_name : nocodb-db hostname : root_db environment : POSTGRES_DB : ${POSTGRES_DB} POSTGRES_USER : ${POSTGRES_USER} POSTGRES_PASSWORD : ${POSTGRES_PASSWORD} volumes : - " ./pgdata:/var/lib/postgresql/data" healthcheck : test : [ " CMD" , " pg_isready" , " -U" , " ${POSTGRES_USER}" , " -d" , " ${POSTGRES_DB}" ] interval : 10s timeout : 5s retries :

LocalAI is an open-source platform for running Large Language Models locally with an OpenAI-compatible API, so you can swap it in behind existing OpenAI client code without paying per-token or sending data off-server. This guide deploys LocalAI using Docker Compose with Traefik handling automatic HTTPS, persistent model and cache directories, and a working chat-completion test. By the end, you'll have LocalAI serving an OpenAI-compatible API securely at your domain. Set Up the Directory Structure 1. Create the project directories: $ mkdir -p ~/localai/ { models,cache } $ cd ~/localai models/ holds downloaded model files; cache/ persists between restarts. 2. Create the environment file: $ nano .env DOMAIN = localai.example.com LETSENCRYPT_EMAIL = admin@example.com Deploy with Docker Compose 1. Add your user to the Docker group: $ sudo usermod -aG docker $USER $ newgrp docker 2. Create the Compose manifest: $ nano docker-compose.yaml services : traefik : image : traefik:v3.6 container_name : traefik restart : unless-stopped environment : DOCKER_API_VERSION : " 1.44" command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirections.entrypoint.to=websecure" - " --entrypoints.web.http.redirections.entrypoint.scheme=https" - " --certificatesresolvers.le.acme.httpchallenge=true" - " --certificatesresolvers.le.acme.httpchallenge.entrypoint=web" - " --certificatesresolvers.le.acme.email=${LETSENCRYPT_EMAIL}" - " --certificatesresolvers.le.acme.storage=/letsencrypt/acme.json" ports : - " 80:80" - " 443:443" volumes : - /var/run/docker.sock:/var/run/docker.sock:ro - ./letsencrypt:/letsencrypt localai : image : localai/localai:latest-aio-cpu container_name : localai restart : unless-stopped volumes : - ./models:/models:cached - ./cache:/cache:cached healthcheck : test : [ " CMD" , " curl" , " -f" , " http://localhost:8080/readyz" ] interval :

LibreChat is an open-source, ChatGPT-style web UI that supports OpenAI, Anthropic, Azure OpenAI, Gemini, OpenRouter, local OpenAI-compatible endpoints, and more — with MongoDB-backed conversation history and Meilisearch-powered search. This guide deploys LibreChat using its official Compose manifest plus a Traefik override for automatic HTTPS. By the end, you'll have LibreChat running with a registration page and multi-provider chat at your domain over HTTPS. Clone LibreChat and Prepare the Environment 1. Clone the LibreChat repository and check out a stable tag: $ git clone https://github.com/danny-avila/LibreChat.git $ cd LibreChat $ git checkout tags/v0.8.3 2. Find the Meilisearch data directory name pinned by this release: $ grep -o 'meili_data_v[0-9.]*' docker-compose.yml | head -1 3. Create the required data directories (replace meili_data_v1.35.1 if the previous command printed a different name): $ mkdir -p data-node images logs meili_data_v1.35.1 uploads $ sudo chown -R 1000:1000 meili_data_v1.35.1 4. Copy the env template and uncomment the UID/GID lines: $ cp .env.example .env $ nano .env UID = 1000 GID = 1000 Override the Compose Stack with Traefik 1. Create a Compose override that adds Traefik and wires the API to it: $ nano docker-compose.override.yml services : api : labels : - " traefik.enable=true" - " traefik.http.routers.librechat.rule=Host(`librechat.example.com`)" - " traefik.http.routers.librechat.entrypoints=websecure" - " traefik.http.routers.librechat.tls.certresolver=leresolver" - " traefik.http.services.librechat.loadbalancer.server.port=3080" volumes : - ./librechat.yaml:/app/librechat.yaml traefik : image : traefik:v3.6.10 ports : - " 80:80" - " 443:443" volumes : - " /var/run/docker.sock:/var/run/docker.sock:ro" - " ./letsencrypt:/letsencrypt" command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirect

If you've ever tried to set up Prometheus by following the official getting-started path, you're likely to find a path that does not follow your infrastructure model. Out of the gate, page one mentions kube-prometheus-stack. Page two wants you to install a Helm chart, and page three assumes you already have a cluster running. The documentation for monitoring plain Linux servers is in there somewhere, but you have to dig for it. When you do find it, the tone suggests you are doing something slightly old-fashioned. If that sounds like your setup, the tooling is making this harder than it actually is. Monitoring a fleet of Linux VMs is fairly simple and has been for years. It is just obscured behind documentation that would prefer to sell you something bigger. Modern infrastructure tooling has quietly decided everyone runs Kubernetes. If you don't, the assumption is that you eventually will. Meanwhile, most real-world infrastructure still runs on VMs. TL;DR: Modern observability documentation often assumes you're running Kubernetes. Most small teams aren't. If you're managing a fleet of Linux VMs, node_exporter plus Prometheus gives you everything you need for infrastructure monitoring with a single lightweight agent and a straightforward deployment model. No cluster required. VMs are often the answer For most small businesses, running VMs instead of Kubernetes does not mean you failed to evolve. Most workloads under a certain scale perform better on VMs: One process per box, predictable resource limits, and the ability to ssh in and look at what's happening, which makes it easier to keep track of the infrastructure as a whole. They're cheaper, both financially and in the mental overhead of running them. Backups and snapshots are straightforward in a way stateful Kubernetes still isn't. There's no control plane that itself needs monitoring and upgrades and care. Kubernetes solves problems that mostly pertain to companies with dozens of engineers and hundreds of service

У большинства self-hosted VPN-панелей одна и та же боль: Docker-стек, внешняя БД, реверс-прокси и куча конфигов, которые надо связать между собой, прежде чем хоть что-то заработает. Мне хотелось наоборот — что-то, что можно закинуть на свежий VPS и поднять меньше чем за минуту. Так появилась РосПанель : self-hosted панель для администрирования личного VPN-сервера на Xray-core , который поставляется одним статическим бинарником . React-фронтенд вшит через go:embed , база — встроенный SQLite, отдельного веб-сервера нет. Поставил, открыл, добавил юзера. Главная идея: один бинарник, ничего лишнего Цель, которая определила всё остальное, — радикальная простота. В отличие от Marzban и 3x-ui, у РосПанели нет Docker-обвязки, нет внешней БД и нет отдельного веб-сервера, который надо настраивать. Всё живёт в одном исполняемом файле: Веб-интерфейс собирается в web/dist и вшивается в Go-бинарник на этапе сборки. Состояние хранится в SQLite (чистый Go-драйвер modernc , то есть без CGO ). Конфиг Xray всегда генерируется из базы и применяется супервизором — SQLite это единственный источник правды, а не JSON, который правят руками. В итоге деплой — это просто положить бинарник и systemd-юнит. Никакой оркестрации, ничего не надо держать в синхроне. Что она на самом деле делает РосПанель — это панель управления (control plane), а не VPN-клиент. Она настраивает и обслуживает ваш собственный сервер: генерирует конфиг Xray, выдаёт ссылки на подписки и показывает статистику. Протоколы из коробки — один конфиг Xray, один набор учёток: VLESS-Vision (TCP/443 + uTLS-fingerprint) Trojan-WS (через fallback на 443) Hysteria2 (UDP с port-hopping) VLESS-gRPC-REALITY (отдельный порт, маскировка под чужой TLS) Маскировка — панель спрятана за секретным путём. Любой другой путь отдаёт сайт-заглушку (11 готовых шаблонов), так что сервер неотличим от обычного хостинга. Без знания /<secret>/ форму логина не найти. TLS, который просто работает — ACME через Let's Encrypt или ZeroSSL, авто-продление и self

Build-in-public. This is the real architecture behind running ~50 local AI agents on 6GB of VRAM — one GPU lock, an eviction watchdog, a resource governor, and a model router. Originally posted on my blog. The question I get most often is some version of "there's no way you run that many agents on a 6GB laptop GPU." The honest answer: not the way you're picturing it. I don't run 50 models at once. I run one model at a time, very deliberately — and most of the engineering is about scheduling, not inference. Here's the actual architecture. The hard constraint: 6GB of VRAM A single consumer GPU with 6GB of VRAM holds roughly one 7B-parameter model at a usable quantization. Two at once? It thrashes — the GPU starts swapping, latency explodes, and eventually a driver out-of-memory can take the whole machine down. I've had the desktop freeze from exactly that. So the first design rule wrote itself: only one heavy model is allowed on the GPU at any moment. That sounds limiting. It isn't — because almost nothing I run is latency-sensitive. A blog post that publishes at 7am doesn't care if it was generated at 6:52 or 6:58. Once you accept that your AI workforce is a batch system, not a chat window, the whole problem changes shape. A lock, not a crowd Every agent that needs the GPU has to take a lock first. It's a simple file-based queue with: FIFO ordering PID-based ownership Stale-lock detection, so a crashed job can't wedge the line forever If an agent can't get the lock within its timeout, it skips gracefully and tries again on its next scheduled run instead of piling up. So at 50 agents, what's really happening is: dozens of cron-scheduled Python workers wake up throughout the day, and the ones that need the model form an orderly line for it. The fleet is huge; the GPU contention is always exactly one. That's the trick. It's less "50 models" and more "50 employees sharing one very busy workstation, politely." Eviction and a VRAM watchdog Even with the lock, idle models l

How I replaced Google Photos, Google Drive, and Google Home with a self-hosted Raspberry Pi 5 setup - and what the full technical stack looks like. There's a quiet moment every tech-literate person eventually hits. You open your cloud storage dashboard, see the number creeping up, and think: I'm paying a subscription fee, every month, forever, just to store my own photos and files on someone else's computer. That was me, but with a bit of added weight. It's not just my data I'm responsible for. Over the years, I've quietly become the unofficial digital curator for my entire family . The person everyone sends photos to after a birthday party. The one who backs up the wedding videos. The one who scans and stores the important documents, passports, contracts, and sentimental things so they don't get lost. My parents, siblings, extended family: if something matters and it's digital, there's a good chance it eventually lands with me. That's a responsibility I take seriously. And for a long time, Google was my answer - until the storage bill started quietly creeping past 2TB, and I started thinking more carefully about what it actually means to hand all of that data over to "big tech" . So I built my own home server. A tiny, almost silent box sitting in my house that now handles everything Google Drive and Google Photos did, plus more, for a one-time hardware cost of £340. This is the story of how I did it, why I did it, and exactly how you can too. Why I Did It The cost was the trigger, but it wasn't the only reason. When you use Google Photos, Google Drive, or any cloud storage service, your files live on their servers. You're trusting a corporation to keep them safe, not snoop through them, not change their pricing, and not shut down the product one day. Google has a long history of killing beloved products. Google Photos itself famously ended its unlimited free tier in 2021. As well as this, recent AI trends and auto opt-in data processing had me thinking there had to

Last year my side project was running on AWS. A t3.small EC2 instance, an RDS PostgreSQL db.t3.micro, an S3 bucket, and a CloudFront distribution. Total bill: $47/month for an app with 200 daily users. Then someone on Reddit told me to look at Hetzner. I now run the same stack on a single CAX21 (4 vCPU ARM, 8GB RAM, 80GB SSD) for €5.49/month. Here's exactly what happened. The Migration What I was running on AWS: Node.js API (Express) PostgreSQL database Redis for sessions Nginx reverse proxy Static files on S3 + CloudFront What I moved to Hetzner: Same Node.js API PostgreSQL installed directly on the server Redis installed directly on the server Nginx + Certbot for SSL Static files served by Nginx Total migration time: one Saturday afternoon. The hardest part was setting up automated backups (solved with a cron job + Hetzner's snapshot API). What Broke Nothing critical, but: No managed database failover. On RDS, if the database crashes, AWS restarts it automatically. On Hetzner, if PostgreSQL crashes at 3 AM, I'm the one fixing it. In 8 months, this has happened zero times. But it could. No CDN by default. My static assets now serve from a single Hetzner datacenter in Germany. For my EU-heavy userbase, this is actually faster than CloudFront. For US users, it's about 50ms slower. I added Cloudflare (free tier) in front and the problem disappeared. Deployment changed. No more eb deploy or push-to-deploy. I wrote a 12-line bash script that SSHs in, pulls from git, runs migrations, and restarts PM2. Takes 8 seconds. Honestly prefer it — I know exactly what's happening. The Cost Comparison at Every Scale This is what surprised me most. The gap isn't just at my small scale — it gets wider as you grow: SpecAWSDigitalOceanVultrHetzner2 vCPU, 4GB$30/mo$24/mo$24/mo€4.50/mo4 vCPU, 8GB$61/mo$48/mo$48/mo€8.50/mo8 vCPU, 16GB$122/mo$96/mo$96/mo€16/mo Hetzner is roughly 5-7x cheaper than AWS at every tier. DigitalOcean and Vultr sit in the middle. 👉 Calculate your exact costs When

I open-sourced MarketEye today. For anyone who missed the first post: MarketEye is a self-hosted competitor price monitor I built because I didn't want to pay $99/month for Prisync. The code is now up on GitHub under MIT license. GitHub: github.com/dachengzi065-gif/marketeye Why open source? Three reasons: 1. People actually asked for it. After my first post here, a few people DM'd me asking to see the code. They're developers too — they want to modify it, extend it, make it their own. That's fair. Selling source code to devs is like selling ice to eskimos. 2. Trust. A closed-source price tracker that "runs on your machine" — you either trust the author or you don't. Open source removes that doubt. You can read every line, check what data leaves your machine (nothing), and build it yourself if you want. 3. Longevity. Self-hosted tools have a dirty secret: if the developer disappears, you're stuck with a broken tool. Open source changes that. Even if I get hit by a bus tomorrow, you can fork the repo and keep going. What this means for the $49 version The Gumroad package still exists. It includes: The same code, pre-packaged Email support (I'll help you set it up) A clear conscience subscription (you're paying for convenience, not software) But honestly? If you can run pip install , just clone the repo. It's free. What's next I'm actively working on: Docker image (one-command deploy) More scrapers (plugins for different sites) Discord/Telegram bot alerts (requested by several people) PRs welcome. Issues welcome. Feedback welcome. 👉 github.com/dachengzi065-gif/marketeye

Local Inference Powers Browser Sign Language, Open-Source Agent Infra, & AI Engineering Guides Today's Highlights This week highlights practical advancements in local AI, featuring a browser-based sign language reader running entirely on-device, new open-source infrastructure for building and evaluating AI agents, and a comprehensive guide to AI engineering from scratch, focusing on building and shipping models efficiently. I Built a Webcam Sign-Language Reader in the Browser (No Cloud) (Dev.to Top) Source: https://dev.to/dev48v/i-built-a-webcam-sign-language-reader-in-the-browser-no-cloud-11hg This article details the creation of a real-time sign language reader that operates entirely within a web browser, without relying on cloud services or model uploads. The developer showcases how to achieve genuinely useful AI functionality, traditionally associated with heavy research labs and GPU clusters, using client-side processing. This approach emphasizes privacy, reduced latency, and accessibility by making advanced AI applications runnable on consumer hardware, specifically within the browser environment. The implementation leverages lightweight models optimized for on-device inference, demonstrating the power of WebAssembly or WebGPU for local execution of machine learning. Such a system offers significant advantages for applications requiring immediate feedback or handling sensitive user data, aligning perfectly with the principles of local AI and empowering developers to deploy sophisticated multimodal solutions without external dependencies. This project serves as an excellent example of practical, self-hosted AI and multimodal processing on consumer hardware. Comment: Running a vision model this complex purely client-side with decent performance is impressive. It really pushes the boundaries of what's feasible for local, privacy-preserving multimodal AI in the browser. trycua/cua — Open-source infrastructure for Computer-Use Agents (GitHub Trending) Source: https