Self-Hosting on Margrop Blog

You Bought an Overseas VPS and a Domain. Now What? 12 Things That Make a Public IP Worth Owning

Sat, 11 Jul 2026 13:30:00 +0800

The short answer

An overseas VPS by itself is a powered, connected room without a memorable street address. A top-level domain by itself is only a sign. Put the domain on Cloudflare DNS and point carefully chosen records at the VPS, and you finally own the sign, the map, the storefront, and a standards-based public entrance.

The result is much more useful than “a place to host a blog.” It is a small, always-on piece of Internet infrastructure where you control the code and the migration path: websites, APIs, webhooks, status pages, monitoring, controlled file sharing, password management, remote-access relays, automation jobs, and a personal AI gateway can all grow from the same foundation.

A public IP is also a door facing a busy street. Automated scanners may try the handle shortly after the server appears. This guide therefore covers both the useful projects and the services that should never be exposed directly.

Take Back Your Remote Desktop: Deploying an All-in-One RustDesk Server Safely

Fri, 10 Jul 2026 22:00:00 +0800

The short version

RustDesk is an open-source remote desktop application designed with self-hosting in mind. When two clients can reach each other directly, screen and input traffic can use a peer-to-peer path. When that direct path fails, a relay server forwards the encrypted traffic. Hosting the server yourself does not eliminate servers; it puts device registration, relay routing, keys, accounts, and logs back under your control.

This guide uses the community-maintained lejianwen/rustdesk-server-s6 image to place the RustDesk OSS hbbs and hbbr services together with a community API and web administration layer in one container. It is a convenient option for homes, labs, and small teams, but it is not an official RustDesk all-in-one distribution. Evaluate the community image, pin a tested tag or digest, back up its persistent data, and rehearse upgrades and rollbacks before treating it as production infrastructure.

Every address in this article uses example.com. No real IP address, private domain, hostname, device ID, account, key, token, cookie, or private registry is shown. The screenshots come from public official or community project pages.

I Put Docker in a Control Room: Portainer CE 2.39.4 Deployment, Daily Use, and Real Traps

Fri, 10 Jul 2026 15:30:00 +0800

Bottom line first

Portainer does not replace Docker. It is a control room for a Docker host. Docker Engine remains the machinery; Portainer organizes containers, images, networks, volumes, and Compose stacks into a web dashboard.

I ran an isolated deployment of portainer/portainer-ce:2.39.4, initialized it, connected the local Docker environment, inspected the dashboard, filtered a disposable container, and created a demonstration stack. The installation is one docker run command. The important lessons are broader: persist /data, understand that /var/run/docker.sock is highly privileged, and never expose the management interface to an untrusted network without protection.

This article contains no complete IP address, real host name, private domain, administrator password, token, cookie, private registry address, or production container name. The screenshots use disposable names, and the container address is redacted.

The Self-Hosted Web Clipboard I Kept Is Just One Text Box

Fri, 10 Jul 2026 15:30:00 +0800

Short version

After trying many cross-device clipboard and note tools, the one I kept for personal use is almost embarrassingly small: minimalist-web-notepad. When you open it, there is essentially one text box. It supports plain text only. There is no account system, no rich text editor, no image upload, no folder tree, no dashboard, and no collaboration layer.

That is exactly why it works as a lightweight self-hosted web clipboard. It is good for moving a short command from one device to another, dropping a temporary note into a browser, reading or writing a tiny text value with curl, or keeping a disposable piece of text for a few minutes. It is not a knowledge base. It is not a password vault. It is a piece of scratch paper on the network.

This post uses the ahfeil/minimalist-web-notepad:latest image with Docker Compose. It also includes one-click scripts for Windows 11, Ubuntu 26.04, and macOS 26, plus two operating modes: manual automatic execution and agent-driven configuration. No private network address, private domain, full machine name, or real secret is shown in this article.

Stop Letting Agents Burn Tokens: Wiring Headroom into NewAPI, OpenClaw, and HermesAgent

Sat, 20 Jun 2026 12:30:00 +0800

TL;DR

I did not replace NewAPI, and I did not point OpenClaw or HermesAgent at an unproven gateway. The actual design is simpler: place Headroom in front of NewAPI, then move only the already validated OpenAI-compatible providers to http://<headroom-host>:8787/v1. The original NewAPI endpoint stays available. Long agent context now goes through Headroom first, gets compressed, then continues to NewAPI for the same routing and model management as before.

The rule that kept the rollout boring was: test first, edit second; migrate only OpenAI-compatible providers that pass; leave non-OpenAI fallbacks alone. This post is both a write-up and a runbook you can hand to an Agent or follow manually.

One sentence let Claude upgrade Ubuntu 22.04 to 24.04: a near-zero-screen-time cross-LTS run

Fri, 19 Jun 2026 10:58:00 +0800

TL;DR

A remote home-lab box had been sitting on Ubuntu 22.04.4 LTS (jammy, kernel 5.15) for a long time. After one sentence — “upgrade the box at 192.168.103.182 to Ubuntu 24.04” — Claude opened a tmux session to babysit the run, brought up a fallback sshd on port 1022 so a mid-upgrade sshd restart would not strand me, then drove do-release-upgrade -f DistUpgradeViewNonInteractive end to end. Twenty-five minutes later the host came back: kernel 6.8.0-124, every service still listening.

This is not a tutorial on do-release-upgrade; the Ubuntu docs already cover that. This is about what an Agent does once it gets an SSH handle on a box, why it does each step, and which pitfalls you have to clear out of the way before letting it loose.

I dockerized AnythingLLM and the container turned into a wound-up squirrel — restarting forever until I handed it that magic 1000:1000

Wed, 17 Jun 2026 20:30:00 +0800

TL;DR

AnythingLLM, Mintplex Labs’ “stuff-anything-in-a-LLM” desktop, ships an official Docker image. In the happy path one docker run is all you need. But the in-container user anythingllm is picky: the host directory you bind-mount has to be owned by 1000:1000, otherwise it can’t write its own SQLite file, the Prisma migration step on startup crashes, and the container enters a restart-crash-restart loop. The fix takes under a minute: chown -R 1000:1000 /your/data/dir, then docker compose up -d again, and it dutifully listens on 3001.

I’ll also explain why Prisma’s file:../storage/anythingllm.db relative path is a footgun, give you a Portainer-ready stack file, and finish with a Q&A on the most common gotchas.

New Chrome Could Not Log In to Bitwarden, but Old Machines Still Worked: A Vaultwarden Compatibility Trap

Mon, 18 May 2026 10:05:00 +0800

TL;DR

The failure looked like a Chrome or Bitwarden extension problem: newly installed computers could not log in to a self-hosted Vaultwarden instance, while existing computers continued to work with the same Bitwarden 2026.4.1 browser extension. The actual root cause was server-side compatibility: the clients were using a newer prelogin endpoint, while the Vaultwarden server was still running vaultwarden/server:1.35.4-alpine, which did not provide /identity/accounts/prelogin/password.

Existing machines were likely protected by an already established login state and local cache. They did not prove that the full first-login API path was still compatible. The correct fix was to back up the Vaultwarden data, upgrade the server image to 1.36.0 or newer, and confirm from logs that the prelogin endpoint no longer returned 404.

All domains, paths, usernames, and deployment details in this article are sanitized. Examples use placeholders such as vault.example.com and /opt/vaultwarden; no internal network or private information is included.

The Best Home for OpenClaw / HermesAgent: Proxmox VE

Wed, 29 Apr 2026 10:00:00 +0800

The Best Home for OpenClaw / HermesAgent: Proxmox VE

If you treat OpenClaw or HermesAgent as just another chatbot, the installation target looks unimportant. It can run on a physical machine, a VPS, a Docker host, or even a daily laptop.

That changes the moment the agent starts receiving messages, running shell commands, reading and writing files, launching browser automation, storing long-term memory, and executing scheduled tasks. At that point, the question is no longer “where can it run?” The real question is: what boundary should contain it?

My conclusion is simple: for long-running personal agents such as OpenClaw and HermesAgent, the most reliable home is not the physical host itself, but a dedicated virtual machine on Proxmox VE.

This is not because Proxmox VE is fashionable. It is because it solves the three problems that matter most for agent infrastructure: data isolation, compute isolation, and backup/restore.