标签：#selfhosting

You self-host S3-compatible storage on bare metal by installing a single Rust binary on a Linux server and pointing any S3 client at it. RustFS installs with one script, listens on port 9000 (S3 API) and 9001 (console), and is Apache 2.0 licensed. Single-node mode is production-ready today; multi-node clustering is still under testing. Every command below is copied verbatim from the official source cited beside it. This sandbox has no Docker daemon, so none of the commands were executed here; they are marked accordingly. Key Stats Fact Source RustFS installs with one command and runs as a systemd service on x86_64 or aarch64 Linux RustFS docs (Linux quick-start) Default S3 API port is 9000; console port is 9001 RustFS GitHub README Default credentials are rustfsadmin / rustfsadmin and must be changed RustFS README + docs RustFS is Apache 2.0 licensed and S3-compatible RustFS GitHub README Single-node mode is production-ready; distributed mode is still under testing RustFS README Feature & Status What is self-hosted S3-compatible storage? A self-hosted S3-compatible storage server is a program you run on your own hardware that speaks the Amazon S3 API. Applications using AWS SDKs, the aws CLI, or MinIO's mc can talk to it without code changes, because the bucket, object, and credential model matches S3. The difference from a cloud bucket is ownership: the disks, the network path, and the uptime are yours. RustFS is one such server, written in Rust and licensed under Apache 2.0. It exposes the S3 API on port 9000 and a web console on 9001, and it stores objects on the local filesystem. Because it is S3-compatible, the same client code that targets AWS S3 also targets a RustFS node. That compatibility is the whole point of self-hosting here: you get an S3 endpoint without renting one. Why run object storage on bare metal? Running object storage on bare metal means installing the server directly on a Linux machine instead of in a container or a managed cloud. The appeal

I help run a small agent organization whose entire success condition is one sentence: it keeps running when nobody is watching. Last week its operator — who does not write code — installed a self-hosted agent gateway on a Mac, from nothing, in one sitting. I logged every place it broke. All eleven below actually happened. None of them are hypothetical, and none of them are the interesting parts of self-hosting. They are the boring parts, which is exactly why nobody writes them down. One framing note before the list. Every individual item here is documented somewhere. What is not documented anywhere I could find is the order , and the fact that fixing item 3 creates item 4, which creates item 5. A non-developer doesn't fail because a step is hard. They fail because step 3's official doc ends before step 4 exists. The eleven 1. Homebrew requires an Administrator account Cause: No Node on the machine, so the install path fell through to Homebrew, which wants admin. Fix: Don't grant admin. Install Node from the official .pkg in the admin account instead, then work in the unprivileged one. Move the part, not the privilege. This turned out to be the single most useful rule of the whole install. Every time the answer was "just give this account admin," it was the wrong answer. 2. Copy-paste doesn't cross macOS user accounts Cause: The clipboard is per-session. Obvious in retrospect, invisible while it's happening — you copy a token in one account, switch, and paste yesterday's clipboard. Fix: /Users/Shared as the only transfer path. Everything moves as a file. 3. npm install -g fails with EACCES Cause: Default prefix is /usr/local , which the unprivileged account cannot write. Fix: npm config set prefix ~/.npm-global 4. It installed, but command not found Cause: Direct consequence of 3. The new prefix's bin isn't on PATH . Fix: One line in ~/.zshrc . 5. The install-scripts prompt keeps coming back Cause: --allow-scripts applies to that invocation only . It looks like the s

Syncthing keeps files synchronized across devices you control, making it one of the most practical tools for a self-hosted knowledge infrastructure that avoids cloud lock-in. Unlike cloud storage platforms, Syncthing uses a peer-to-peer model where each device holds its own copy of synced folders and exchanges changes directly with trusted peers. There is no central server that owns your data, no subscription account, and no vendor lock-in. The project is open-source and community-driven, with more details at syncthing.net . This architecture makes Syncthing especially useful for knowledge workers who manage markdown notes, research documents, PDFs, and project files across a desktop, laptop, home server, and possibly a phone. The tool is simple in concept but requires careful setup to avoid common pitfalls like treating sync as backup or syncing folders that should remain isolated. What Syncthing Is and Is Not Syncthing synchronizes files between two or more devices. Each device maintains its own copy of a folder, and changes propagate between trusted peers. Discovery and relay services may help devices find each other across networks, but the storage model remains local-first. The Syncthing documentation covers installation and configuration in detail. The calm but important opinion is this: Syncthing is excellent when treated as sync infrastructure. It becomes dangerous when treated as backup. It is not a cloud drive. It is not a complete backup system. It is not a collaboration suite. It is a private, peer-to-peer file synchronization tool. Why Syncthing Matters for Knowledge Management Knowledge management is not only about note-taking. It is also about where knowledge lives, how it moves, and whether it remains accessible over time — see the knowledge management guide for the broader picture of tools, methods, and self-hosted platforms this fits into. A useful personal or team knowledge system often contains: markdown notes PDFs and papers diagrams and screens

The problem every self-hoster hits You built something. A local API. A Minecraft world for your friends. A self-hosted dashboard. An ERP running on the office machine. It works great — on your LAN. The moment you want someone outside to reach it, the fun begins: Port forwarding? Good luck if you're behind CGNAT, a corporate firewall, or an ISP that doesn't give you a public IP. VPN? Now every person who wants access has to install a client, join a network, and stay connected. Overkill for "let me show you this one page." Cloud deploy? Now you're maintaining two environments, paying for a VPS you didn't need, and shipping data somewhere it doesn't have to live. What most people actually want is simpler: take this one local port, give it a public address, done. That's exactly what FRP does. What FRP is FRP (Fast Reverse Proxy) is an open-source tool by fatedier that exposes a local service behind a NAT or firewall to the public internet. It's battle-tested, written in Go, and has been the go-to answer in self-hosting communities for years. The model is clean — two pieces: frps (the server) — runs on a machine with a public IP (a $5 VPS is plenty). frpc (the client) — runs on your local machine, the one with the service you want to expose. The client opens an outbound tunnel to the server. The server listens on a public port and forwards traffic back through the tunnel. NAT and firewalls don't matter because the connection is initiated from inside . [Visitor] → [frps on public VPS:7000] ⇄ tunnel ⇄ [frpc on your laptop] → [localhost:8080] That's the whole idea. It works for TCP, UDP, HTTP, HTTPS. People run Minecraft servers, remote desktops, internal dashboards, and dev previews through it every day. The catch: config files FRP works great. The friction isn't the protocol — it's the workflow . To run frpc , you write a TOML/INI config file: serverAddr = "203.0.113.10" serverPort = 7000 auth.token = "your-secret-key" [[proxies]] name = "my-web" type = "tcp" localIP = "1

Installing Docker on Ubuntu should be simple, but in practice several Docker-shaped options compete for the same command name, each with different packaging, upgrade behavior, and security implications. This guide compares every major install path so you can pick the one that fits your machine. The options you will encounter include: docker.io from Ubuntu repositories docker-ce from Docker's official APT repository Docker from Snap Docker Desktop manually downloaded .deb packages the Docker convenience script rootless Docker Although they all provide container tooling, they are not interchangeable packages. The best choice depends on whether the machine is a developer workstation, a CI runner, a small server, a self-hosting box, or a production host. My default recommendation is calm but firm: for most technical users on normal Ubuntu machines, install Docker Engine from Docker's official APT repository. Use Ubuntu's docker.io only when distribution integration matters more than upstream Docker packaging. Avoid the Snap package unless you specifically want Snap behavior and understand its limits. Rootless Docker is worth knowing about, but it is not automatically the best default for every machine. This guide explains the tradeoffs, covers post-install security, and gives you clean installation paths for each method. Once Docker Engine is running, the Docker Cheatsheet is your daily command reference, and the Docker Compose Cheatsheet covers multi-container setups. Both sit alongside Git, VS Code, and CI/CD guides in Developer Tools: The Complete Guide to Modern Development Workflows . Quick Recommendation The table below summarizes which install path fits common scenarios. Use case Recommended install Developer workstation Docker official APT repo CI runner Docker official APT repo, version pinned if needed Small self-hosted server Docker official APT repo Production server Docker official APT repo, controlled upgrades Ubuntu-only conservative system Ubuntu docker.

Vercel m'a longtemps convenu. Tu pousses ton code, trente secondes plus tard c'est en ligne avec un certificat valide, un CDN et des previews par branche. Pour démarrer un projet, je ne connais rien de plus confortable. Le problème arrive après, quand le projet vit. La facture grimpe avec le trafic et les fonctions serverless, certaines fonctionnalités propriétaires deviennent compliquées à reproduire ailleurs, et tu finis par ne plus vraiment savoir où ni comment ton app tourne. C'est un excellent point de départ, et un piège dès qu'on veut maîtriser son coût et son infra. Pour ce portfolio comme pour plusieurs projets clients, j'ai pris le chemin inverse. Un VPS à quelques euros par mois, une image Docker, un reverse proxy, un pipeline maison. L'idée n'est pas de revenir à l'âge de pierre du déploiement par FTP : je garde le « git push et c'est en ligne », mais sur une machine que je contrôle de bout en bout. Voici comment c'est câblé, et les deux ou trois endroits où je me suis fait avoir. L'image Docker : tout repose sur le mode standalone La pièce qui change tout, c'est output: "standalone" dans next.config.ts . Au build, Next trace exactement les fichiers nécessaires au runtime et les recopie dans .next/standalone/ . On passe d'une image d'environ 1 Go à environ 200 Mo. Sans ça, tu traînes tout node_modules dans ton conteneur de prod pour rien. Le Dockerfile est multi-stage : une étape pour installer les dépendances, une pour builder, une dernière qui ne garde que le strict nécessaire. # deps : installe les dépendances (cache Docker optimal) FROM node:22-alpine AS deps WORKDIR /app COPY package.json yarn.lock .yarnrc.yml ./ RUN corepack enable && yarn install --immutable # builder : build l'app FROM node:22-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN corepack enable && yarn build # runner : image finale, non-root FROM node:22-alpine AS runner WORKDIR /app ENV NODE_ENV=production RUN addgroup -g 1001 nodejs && a

n8n is the kind of tool you start using lightly and then quietly route half your operations through. At which point "it's running on someone's cloud seat, metered per execution, with my API keys living on their servers" starts to feel less great. Self-hosting fixes all three — flat cost, no execution cap, and your keys stay on a box you own. With Docker it's a fifteen-minute job. How much server it actually needs Honest numbers first, so you don't over- or under-buy: ~2 GB RAM is the sweet spot — n8n plus its Postgres database plus normal workflows sit comfortably here. 1 GB works if your workflows are light, but you'll notice it on bigger runs. 4 GB if you do heavy parallel executions or push large payloads through. n8n isn't CPU-hungry at rest; it spikes during runs. A 2-core box is fine for most setups. (More on matching specs to workload in the sizing guide .) The Docker setup On a fresh Ubuntu/Debian box, install Docker: curl -fsSL https://get.docker.com | sudo sh Make a folder and a docker-compose.yml — n8n with a persistent volume and Postgres: services : n8n : image : docker.n8n.io/n8nio/n8n restart : always ports : - " 127.0.0.1:5678:5678" environment : - N8N_HOST=n8n.yourdomain.com - N8N_PROTOCOL=https - WEBHOOK_URL=https://n8n.yourdomain.com/ - DB_TYPE=postgresdb - DB_POSTGRESDB_HOST=db - DB_POSTGRESDB_PASSWORD=change-me volumes : - ./n8n-data:/home/node/.n8n depends_on : [ db ] db : image : postgres:16 restart : always environment : - POSTGRES_PASSWORD=change-me - POSTGRES_DB=n8n volumes : - ./db-data:/var/lib/postgresql/data sudo docker compose up -d Two things worth pointing out: the volumes ( n8n-data , db-data ) are what keep your workflows alive across restarts and upgrades — don't skip them. And n8n is bound to 127.0.0.1 , not 0.0.0.0 — it's not exposed to the internet directly. That's deliberate; the next step handles access safely. Access: HTTPS or a tunnel Public URL (needed for OAuth nodes and webhooks): point a subdomain at the server and run

Every time I started a side project, I rebuilt the same five things before I wrote a single line of the actual idea: auth, a database, file uploads, a deploy pipeline, and TLS. Different domain, same plumbing. By the third project I was copy-pasting my own docker-compose.yml from a folder two repos over and renaming things until they stopped erroring. So I stopped. I froze that plumbing into one boilerplate — PocketBase + Next.js + Caddy on a single cheap VPS — and now I ship every side project on it. Same shape every time: clone, rename, write the part that's actually new, push. The thing I care about most isn't the speed, though. It's that I stopped paying for it. A handful of real projects now run on this setup for a few euros a month, total — not a stack of per-service SaaS bills that each want $25 here and $20 there before you've shipped anything. No Vercel seat, no managed Postgres, no Auth-as-a-Service, no object-storage line item. Here's the whole thing. Why this stack The trick that makes the cost collapse is PocketBase . It's a single Go binary that gives you, in one process: Auth — email/password, OAuth, the works, with a real users collection A database — SQLite, with a schema you manage from an admin UI Realtime — subscribe to collection changes over SSE File storage — uploads handled, with on-the-fly thumbnails An admin dashboard — at /_/ , for free That's four or five separate SaaS products collapsed into one binary that runs anywhere and stores everything in a folder. Compared to wiring up Supabase or Firebase, the mental model is tiny: it's one process and one data directory. Back up the directory and you've backed up the entire app — database, uploaded files, auth tokens, all of it. For the front I use Next.js (App Router, React Server Components) because that's where I'm fastest, and Caddy as the reverse proxy because it gets you automatic HTTPS with zero config — it provisions and renews Let's Encrypt certificates on its own. And it all lives on