标签：#selfhosted

I run a small self-hosted observability tool on the cheapest VPS I could find on purpose: 2 cores, 2 GB RAM, 20 GB SATA SSD . It ingests errors, traces and metrics from two low-traffic sites of mine. The stack is three containers — a Go app, PostgreSQL, and ClickHouse. One evening docker stats showed ClickHouse sitting on 880 MB of its 1 GB limit and the box swapping, with basically zero events coming in. So I went looking for where the memory and disk had gone. The answer turned out to be a good lesson in how a database can spend almost all of its I/O talking to itself. 543 KB of my data, 579 MB of ClickHouse talking about ClickHouse First thing I checked: how much data had my app actually stored versus how much ClickHouse had stored about itself . My application database: 543 KB, 16k rows The system database: 579 MB, 46.3M rows Roughly a thousand to one. Disk was 12 GB used out of 20 — on a tool that had recorded half a megabyte of real telemetry. The culprit was ClickHouse's own system logs, several of which have no TTL by default and therefore grow forever: trace_log — 404 MB, 26M rows (the query profiler writes here; it's on by default, sampling once per second) asynchronous_metric_log — 16.6M rows text_log — 132 MB plus query_log , latency_log Only metric_log , processors_profile_log and part_log ship with a TTL. Everything else just accumulates. Then I looked at the insert rate over 30 seconds: trace_log — 227 rows/s asynchronous_metric_log — 157 rows/s text_log — 44 rows/s my application — about 5 rows/s 98.8% of all inserts were ClickHouse narrating its own internals. The part that's expensive beyond disk Here's the number that made me stop. Over the same 30 seconds: rows inserted : 16,222 rows merged : 11,007,643 That's a 1 : 678 ratio. For every row written, the engine rewrote 678 already-sitting rows. The mechanics: MergeTree drops every insert into its own data part, then merges parts into bigger ones so reads stay fast. When the table is small this is

Coolify's one-line install script is great — until it isn't. Right now it officially supports Ubuntu 20.04, 22.04, and 24.04 LTS. If you're running anything newer (Ubuntu's already on 26.04 LTS), the script won't work and you're left doing it manually. This is that manual walkthrough — set up in the order that fits a security-first VPS workflow rather than the order Coolify's own docs use. If you've been following along with the Ansible playbooks from earlier in this series, this picks up right where that left off. Minimum Hardware Requirements CPU: 2 cores Memory: 2 GB RAM Storage: 30 GB free Coolify can technically run below this, but it's not recommended. Prerequisites Before touching Coolify itself, you'll need: SSH access to your VPS CURL installed Docker Engine installed If you're reconnecting to a server you've rebuilt or re-provisioned, clear the old fingerprint first: ssh-keygen -f '/home/your-path/.ssh/known_hosts' -R 'your-vps-ip' Installing SSH If you followed the earlier videos in this series, OpenSSH is already installed. If not: sudo apt update && sudo apt install -y openssh-server Confirm it's running and check which port it's listening on (you should have already changed this from the default 22 — see the VPS security video): sudo systemctl status ssh sudo ss -tulpn | grep ssh Installing CURL sudo apt update && sudo apt install -y curl curl --version curl and ca-certificates also get installed as part of the apt-update Ansible playbook below, so this may already be handled. Running the First Ansible Playbook Connect Ansible to the VPS: ANSIBLE_HOST_KEY_CHECKING = FALSE ansible -i ./inventory/hosts vpsDemo -m ping --user root --ask-pass Then run the update playbook: ansible-playbook ./playbooks/apt-update.yml --user root -e "ansible_port=22" --ask-pass --ask-become-pass -i ./inventory/hosts If you haven't set up the Ansible inventory and playbooks from the earlier videos, do that first — this guide assumes they're already in place. Installing Docker

Project: https://quven.tv/ Security model: https://quven.tv/security/ For the last 18 months, I have been building Quven, a self-hosted media server for personal movie, TV, and documentary libraries. I started with a seemingly simple goal: let people keep their media on their own hardware while giving them a polished client experience. Playback quickly became the hardest part. A media server does not simply send a video file to a screen. It has to understand the source, the client, the network, and the user's choices, then select a playback path without making any of that complexity feel visible. These are some of the lessons I learned. 1. "Can this file play?" is the wrong question The real question is whether a particular client can play a particular combination of: container; video codec and profile; audio codec and channel layout; subtitle format; resolution, bitrate, and frame rate; HDR format; network conditions. A client might support the video codec but not the audio track. A browser might decode the video but require a different container. Enabling an image-based subtitle can turn an otherwise direct-playable file into a video transcode. Playback compatibility is therefore not a boolean property of a file. It is a negotiation between the source and the active client. 2. Direct play should be the preferred outcome, not a promise Direct play preserves the original file and avoids unnecessary server work. When the client supports the selected combination, it is usually the best path. But forcing direct play at all costs produces a worse experience. A high-bitrate file may technically be supported while still exceeding the available connection. A selected subtitle might require burning into the video. A television may accept a container while rejecting one of its audio formats. The practical hierarchy I settled on is: Direct play when the complete source is compatible. Remux when the streams are compatible but the container is not. Transcode only what must chan

I self-host Umami for my SaaS, ParserBee . The main reason I picked it: privacy-friendly, cookie-less, first-party analytics that adblockers supposedly leave alone because the script comes from your own domain. That last assumption turned out to be wrong, and the reason is the subdomain name itself. Writing it up because the fix is small and the failure mode is silent. The problem My Umami instance ran at umami.parserbee.com , so the tracker was loaded like this: <script defer src= "https://umami.parserbee.com/script.js" data-website-id= "..." ></script> The EasyPrivacy filter list (used by uBlock Origin, Brave Shields, AdGuard, and most other blockers) contains a rule that matches the Umami tracker by hostname pattern, along the lines of: ||umami.*/script.js It doesn't target a specific company's server. It targets any host whose subdomain is literally named umami serving a file called script.js . Which is exactly how most of us name things when self-hosting: umami.mydomain.com , plausible.mydomain.com , matomo.mydomain.com . The filter lists know this convention, and they have rules for it. The result: every visitor with an adblocker never loads the script. No errors on your side, no console noise, nothing in the Umami logs. The traffic just quietly never shows up. I only caught it because signups were arriving from campaigns that Umami claimed nobody clicked; the server logs and Stripe disagreed with the analytics, and the server logs were right. The fix Serve the same Umami instance from a second hostname that no filter list matches. No proxying, no renaming files, no changes to the Umami install itself. I added u.parserbee.com as an alias for the same service: 1. DNS record. A CNAME (or A record) for u.parserbee.com pointing at the same server as the existing umami.parserbee.com . 2. Reverse proxy. Add the new hostname to the existing Umami site config so both route to the same instance. I run Umami in Docker behind Coolify, where this is just adding a second d

The "Obvious" Math That's Wrong Engineer A: "Datadog is $15K/month. Prometheus is free. We should self-host." Engineer B: "But we'd need to pay an SRE to run it. That's $150K/year." Engineer A: "Prometheus doesn't need a full SRE. It's easy." Engineer B: "Famous last words." This conversation happens at every company. Both sides have points. The real math is more complex. The Total Cost Breakdown Managed (Datadog, New Relic, Dynatrace) : Licensing: $X/month (scales with hosts, events, logs) Integration time: 1-2 weeks per service Training: 1 day per new hire Ongoing: minimal Self-hosted (Prometheus + Grafana + Loki + Alertmanager) : Infrastructure: hosting costs (~$500-$5000/month depending on scale) Initial setup: 2-4 weeks of engineering time Ongoing maintenance: 10-20% of 1 FTE Upgrade costs: quarterly, each upgrade ~1 week Storage growth: ~20% per year Expertise: junior → senior SRE hire required The honest answer: managed is cheaper for teams under 50 engineers. Self-hosted becomes cheaper around 200+ engineers if you can run it well . The Real Variables It's not just licensing cost vs. hosting cost. These factors matter more: 1. Data volume growth Managed tools charge per GB ingested or per metric. If your logs 10x, your bill 10x's. Self-hosted scales linearly with compute. You control the growth. 2. Retention requirements Managed tools often charge extra for long retention. Self-hosted you store as much as your disk allows. 3. Cardinality Prometheus dies at high cardinality. Datadog handles it but charges more. High-cardinality metrics are where self-hosted breaks. 4. Incident rate Heavy incident load means heavy query load on your monitoring tools. Self-hosted needs bigger compute for this. 5. Team expertise If your team has never run Prometheus, you'll spend 6 months in the pit learning cardinality mistakes, retention tuning, and HA setups. That's not free. The Break-Even Calculation Rough calculation for a 50-engineer startup: Managed (Datadog) : - Licensi

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