A Hands-Off Server — The Small cron Automations That Keep It Running

Self-Hosting Build Guide, Part 14 (final). Backups (Part 12) and sync (Part 13) all have to run “at a set time, on their own.” That engine is cron.

← Previous: Part 13 — My Notes on My Server (Obsidian LiveSync)

TL;DR

• cron is the built-in Linux scheduler that runs commands at set times — nothing to install
• What our server does on its own every day: backup · DB dump · cache cleanup · health check · summary
• One crontab line = minute, hour, day, month, weekday + the command to run
• Trap 1: cron has almost no PATH → without absolute paths you get “command not found”
• Trap 2: silent failure — if you don’t log, you find out days later that it never ran

1. What cron Is — an Alarm Clock With Nothing to Install

cron ships with Linux by default. Register a time and a command — “run this script at 4:30 every morning” — and as long as the machine is on, it runs on its own. In self-hosting, almost every repetitive chore can be handed to cron.

2. Reading One crontab Line

The list of jobs is called the crontab. One line is five time fields + a command.

A * means “every.” So 30 4 * * * means 4:30 every day.

30 4 * * *   /home/user/bin/db-dump.sh    >> /var/log/db-dump.log 2>&1
0  5 * * *   /home/user/bin/backup.sh      >> /var/log/backup.log 2>&1

3. What Our Server Does Every Day

Small cron jobs stack up into a “hands-off server.”

• DB dump — the database to a safe file (before the backup)
• File backup — shipped to a NAS (Part 12)
• Cache cleanup — clear piled-up temp files and expired cache
• Health check — is the service alive? alert if it died
• Summary — yesterday’s visitors and errors on one page

4. The Three Traps Beginners Always Hit

① No PATH. A command that worked fine in your terminal dies under cron with “command not found.” cron runs in a minimal environment with a nearly empty PATH. Fix: use absolute paths (/usr/bin/python3), or set PATH at the top of your script.

② Silent failure. cron won’t show errors on screen. By default it only mails them, and nobody reads that. So, as in the example above, redirect with >> logfile 2>&1 to capture output and errors to a file — that’s how you trace a job that didn’t run.

③ Time zone. Check whether the server clock is UTC or your local time. Aim 30 4 * * * at “4:30 a.m.” and, if the server is on UTC, it may actually run in the early afternoon your time.

5. The Compounding of Small Automations

Each cron job is trivial — one line for backup, one for cache cleanup. But they stack, and the server reaches a state where it takes care of itself without you touching it daily. That’s the whole goal of self-hosting: build it, and let it keep running even after you forget about it.

This series comes full circle here too. We started with an empty computer (Part 1), put up a blog, attached a domain, locked it down, backed it up, and now made it run on its own. What’s left is to stand one up yourself.

In One Line

cron is the engine behind “at a set time, on its own.” One line: minute, hour, day, month, weekday + command. Watch just three things — use absolute paths, keep logs, and check the time zone. Stack up small automations and the server stops needing your hands.

My Notes on My Server — Self-Hosting Obsidian LiveSync + CouchDB

Self-Hosting Build Guide, Part 13. Once the blog lives on your server, your notes can too.

← Previous: Part 12 — Backing Up to a NAS Every Night (tar+ssh)
→ Next: Part 14 — A Hands-Off Server (cron)

TL;DR

• Obsidian’s official Sync is a monthly subscription — sync your notes to a database on your own server for $0 plus data ownership
• How: the Self-hosted LiveSync plugin ↔ CouchDB (a Docker container), real-time and bidirectional
• Always bind CouchDB to 127.0.0.1 only — beware Docker’s habit of opening it on 0.0.0.0
• Reach it only from your own devices: inside a private network (a VPN mesh), never on the open internet
• War story: the culprit behind ERR_SSL_PROTOCOL_ERROR wasn’t the certificate — it was “no server running behind it”

1. Why Self-Host Instead of Official Sync

Obsidian is a note app, and to see the same notes on multiple devices you need sync. Official Sync works well but it’s a monthly subscription. And your notes pass through someone else’s server.

You already have a server running for the blog, so you can put note sync on top of it.

The price is “configure yourself.” Set it up once and it’s as smooth as the official option after that.

2. The Shape — Plugin ↔ CouchDB

CouchDB is a database good at exchanging changes in real time. The LiveSync plugin pushes to CouchDB whenever a note changes, and other devices pull from it.

flowchart LR
    PC[Laptop Obsidian] -->|changes| DB[(CouchDB / your server, Docker)]
    Phone[Phone Obsidian] -->|changes| DB
    DB -->|sync| PC
    DB -->|sync| Phone

3. Never Open It on 0.0.0.0

This is the most important part. Spin up CouchDB with plain Docker and its port opens on 0.0.0.0 (every network interface). Now another device on the same Wi-Fi — even something past a misconfigured router — can reach your database.

ports:
  - "5984:5984"             # dangerous: 0.0.0.0, exposed on every interface
  - "127.0.0.1:5984:5984"   # safe: only the computer itself

Bind to 127.0.0.1 only and it’s invisible from outside the server. So how does your phone connect? Only from inside a private network (a VPN mesh). Build a virtual LAN that links just your own devices, and expose CouchDB over https only within it. To the whole internet it stays private.

4. War Story — ERR_SSL_PROTOCOL_ERROR

After finishing the setup I opened the https address and the browser spat out ERR_SSL_PROTOCOL_ERROR. Naturally I assumed it was a certificate problem and stared at certificates for a long time. It wasn’t.

The real cause was simple: the CouchDB container itself wasn’t running. The https front end was set up, but with no server behind it to answer, the TLS connection never completed and the browser reported an “SSL error.”

Lesson: an “SSL error” isn’t always about the certificate. Split the front end (address, cert) from the back end (the actual server), and check the back end is alive first. A quick curl against the backend port settles it in five seconds.

In One Line

You can bring note sync onto your own server too — the LiveSync plugin + CouchDB means $0 in subscription. Just bind CouchDB to 127.0.0.1 and reach it only over a private network. And when you hit ERR_SSL_PROTOCOL_ERROR, suspect a dead back end before the certificate.

Backing Up to a NAS Every Night — tar+ssh (and Why Not rsync)

Self-Hosting Build Guide, Part 12. We secured the server (Part 11). Now: how to save the data even when the server dies.

← Previous: Part 11 — Free WordPress Defense (Wordfence)
→ Next: Part 13 — My Notes on My Server (Obsidian LiveSync)

TL;DR

• Self-hosting without backups is a time bomb — one dead disk and your posts, photos, and database vanish at once
• Every night a cron job tars the important folders and ships them to a NAS over ssh
• We deliberately skipped rsync (which needs its own daemon on port 873) — ssh is already open, so zero extra ports
• The DB dump must finish before the file backup runs, so that dump is included in the same bundle — order creates consistency
• “The backup ran” and “the backup succeeded” are different — a 0-byte file is a failure

1. No Backups = a Time Bomb

Putting a blog on your own computer means the backups the cloud used to handle are now your job. One SSD reaches end of life, or one mistyped command, and months of posts, photos, and databases disappear in an instant.

The rule is simple: back up to a different physical device, automatically, every day. Manual backups always get forgotten.

2. Why tar + ssh Instead of rsync

For backups, most people reach for rsync — fast, with incremental sync. But to use rsync properly with a NAS (here, a Synology) you have to turn on its rsync daemon (port 873). That’s one more open port.

Our data is small, so bundling it whole every day costs nothing. In that case there’s no reason to pay the price of another open port. Shrinking attack surface is almost always the right call in self-hosting.

3. A One-Line Backup

tar czf - /important/data/folder | ssh -p <port> [email protected] "cat > /backup/site-$(date +%F).tgz"

tar czf - bundles the folder and streams it to stdout, and ssh catches that stream and drops it as a file on the NAS. No temp file in the middle, so it uses less disk too. The date ($(date +%F)) in the filename means each day stacks under a different name.

4. Order Creates Consistency — DB First

You can’t just copy a database’s folder. Copy it mid-write and you back up a half-written state. So first dump the DB safely to a file, and the file backup must run after that dump finishes.

flowchart LR
    A[04:30 DB dump] --> B[dump file created]
    B --> C[05:00 file backup
bundles the dump]
    C --> D[ship to NAS]

That’s why the two are staggered. The order of the two cron jobs is the consistency of the backup.

5. Verify “Success”

The most common illusion: if cron fired on schedule, you assume the backup happened. But running is not succeeding. If the disk was full or the NAS briefly went down, you’re left with an empty 0-byte file.

• After the backup, check the size of the file that was created
• If it’s below a threshold, treat it as failed and send an alert
• Auto-delete old backups (rotate) so the disk doesn’t fill up

Add those three lines and your backup escapes the classic trap of “I thought it was there, but it was empty.”

In One Line

Back up to another device, automatically, every day. tar czf - … | ssh ships to a NAS without opening one more port. DB dump first, then the file backup. And check the size to verify “success” — an empty backup is not a backup.

Free WordPress Defense — Wordfence’s Free Tier and the Premium Trap

Self-Hosting Build Guide, Part 11. The bots already arrived back in Part 8. Now we post a guard at the door.

← Previous: Part 10 — What Not to Publish (Privacy Review)
→ Next: Part 12 — Backing Up to a NAS (tar+ssh)

TL;DR

• WordPress runs over 40% of the web — which makes it the No.1 target for automated attack bots
• Wordfence’s free tier gives you a firewall (WAF), two-factor auth (2FA), and a malware scanner — cost $0
• The trap: after install, the screen hides the free option and pushes the paid plan ($149/yr) — the free key hides in a small underlined link
• The only real free-vs-paid difference is “firewall rules arrive 30 days later” — irrelevant for a personal blog
• The extended firewall must sit in front of PHP to truly block — one line in .htaccess, and back it up first

1. Why WordPress is a Target

WordPress powers more than 40% of all websites. High market share means that, from an attacker’s view, a single vulnerability can hit tens of millions of sites.

As we saw in Part 8, the moment you publish a domain, brute-force attempts hit the login page within 24 hours — not humans, but automated bots. They also constantly probe known holes in plugins and themes. So WordPress is a system where “if it’s up, a guard goes up immediately.”

2. What the Free Tier Gives You

What a personal blog actually needs is the first three (firewall, 2FA, scan) — all free. The real-time IP list only matters for large, high-value targets.

3. Finding the Free Key — the Store’s Paid Trap

After installing, a “get your license” screen sends you to the Wordfence store. This is where it gets confusing.

• The big blue button = “real-time protection” = paid ($149/yr). Sometimes two items are pre-added to the cart so it looks even pricier.
• The free key hides below in a small underlined link: I'm OK waiting 30 days for protection updates.
• Click that and a free license key arrives by email. Paste it into the plugin. Done. Cost $0.

It looks like a checkout page, but you never have to pay. The whole task is finding that one sentence about waiting 30 days.

4. Real Defense Sits in Front of PHP — the Extended Firewall

In its default state the firewall runs inside WordPress (PHP). That means an attack request has already reached PHP before it gets inspected. One step too late.

Turning on “Optimize the Firewall” adds one line to the web server config (.htaccess) so requests are checked before PHP runs:

php_value auto_prepend_file '/var/www/html/wordfence-waf.php'

flowchart LR
    V[Visitor/Bot] --> W[Extended firewall
before PHP]
    W -->|clean| P[PHP / WordPress]
    W -->|attack| X[Blocked]

⚠️ Back up .htaccess before enabling this. Depending on your server, that one line can throw a 500 error — and the fix is to restore the backed-up .htaccess. Also, start in “learning mode” for a day or two so it learns your normal traffic, then it switches to protection automatically.

5. Hide the Login Itself (Bonus)

/wp-login.php is an address the whole world knows. A separate plugin lets you move the login to a different path, so the door bots keep knocking on simply disappears. Where you moved it stays secret, of course — that’s the whole point.

Add 2FA on top, with a “remember this device for 7 days” option, and you keep the security without typing a code every time.

In One Line

The free Wordfence tier is enough to defend a personal blog. On the paid-nudge screen, just find the small “OK waiting 30 days” link and it’s $0. Back up .htaccess before the extended firewall, hide the login path, turn on 2FA. It’s not about money — it’s a few clicks.

What Not to Publish — Privacy Review for Self-Hosting Posts

Self-hosting build series, Part 10. Locking down the server matters; so does locking down the story you write about it.

← Previous: Part 9 — Invisible Bridge: Cloudflare Tunnel
→ Next: Part 11 — Free WordPress Defense (Wordfence)

TL;DR

• A self-hosting post inherently publishes the shape of your server — a tightrope between tutorial value and reconnaissance data.
• What I actually leaked: the Linux account name, the mini-PC internal IP, and a personal email (passwords and tokens, luckily, did not leak).
• Five things to redact: secrets · personal info · internal network · file paths · frontmatter.
• A leaked secret can only be rotated, never un-leaked — search engines have already cached it.
• One line of grep before publishing lets the machine sweep for you.

1. What I actually leaked

After happily writing nine parts, I looked again — and found these scattered through the text.

• /home/my-account/... — the Linux account name, sitting right in the path. A target for SSH brute-force attempts.
• http://192.168.x.x:3001 — the mini-PC internal IP, effectively a sketch of my home network.
• A personal Gmail address that slipped into a line about the domain.

Passwords and tokens I had, luckily, written as example values like ${VAR} or <openssl rand -hex 24>, so they were safe. But the three above were real.

The problem is that a public blog is permanent. Search engines index it; caches keep it. Deleting does not undo it. So if a secret has leaked, you don’t delete it — you rotate it immediately.

2. The five things to redact

⑤ is the surprising one. In Markdown, the top of a file has metadata fenced by --- (frontmatter: author, date, filename, and so on). If the publishing conversion slips just once, this gets dumped into the body as a code block. One of my own posts was doing exactly that — exposing its entire frontmatter.

3. Don’t delete — “generalize”

The key is substitution, not deletion. Keep the tutorial value; hide only the parts that are really mine.

Spelling it out as <openssl rand -hex 24> — “generate your own value here” — actually helps the reader follow along. Generalizing turns out to be the friendlier tutorial.

4. An automatic pre-publish check (one line of grep)

Catch it by eye every time and it will eventually slip. Before publishing, let the machine sweep.

grep -rEn '/home/[a-z]+|[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+|@(gmail|naver)\.com|_TOKEN=|_KEY=|PASSWORD=' my-posts-folder/

This catches account paths, IPs, personal email, and secret traces in one pass. The result must be zero lines before you publish. If only placeholders like ${VAR} or <...> remain, you pass.

After publishing, look at the actual public page once more — a cache may still be serving the old version.

curl -s https://your-domain/post-slug/ | grep -E '/home/|192\.168\.|@gmail'

5. The bigger question — should this be public at all?

Even after redacting every detail, one problem remains: the post itself is a map of my infrastructure.

I run private operational tools that I never write about. No matter how well I hide keys and IPs, the mere fact that “a management tool with this shape lives here” is reconnaissance.

So order matters. Decide “should this series be public?” first, and run the redaction above only on what you’ve chosen to publish. What can be hidden, and what should never be written at all, are two different layers of the problem.

One-line takeaway

If there’s a P0 for locking down the server, there’s a P0 for locking down the writing too. Generalize the five — account name, internal IP, personal email, secrets, frontmatter — into placeholders, and check with one line of grep before publishing. A leaked secret can only be rotated, so the cheapest move is never to write it down.

Self-hosting deployment story Part 6. A 30-minute decision that lasts a lifetime.

TL;DR

• Comparison of five domain registrars: Gabia, Whois, GoDaddy, Namecheap, Cloudflare
• Star Whale picks Cloudflare Registrar — cost + DNS + Tunnel + Email in one account
• .org is about $10/year, 30–50% cheaper than Korean registrars
• Caveat: 60-day transfer lock after registration; WHOIS privacy protection is free

1. Choosing a Domain Name

It took three days to settle the name. Here is the candidate comparison.

→ Prioritizing the metaphor: separate the brand name (Star Whale) from the domain (sticknstone). It reads naturally once explained on the About page — “Stick & Stone is an ancient navigator’s tool that pointed at the stars with small stones and sticks; Star Whale sets out on a deep voyage toward that star.”

2. Comparison of 5 Registrars

flowchart LR
    A[Domain Purchase] --> B[Gabia·Whois
Domestic]
    A --> C[GoDaddy
International]
    A --> D[Namecheap
International]
    A --> E[Porkbun
International Startup]
    A --> F[Cloudflare
Registrar]

    B -. Expensive/Renewal Pressure .-> X[Rejected]
    C -. Aggressive Marketing .-> X
    D -. Average .-> Y[2nd Place]
    E -. Good Price .-> Y
    F -. Cost+Integration .-> Z[Selected]

    style F fill:#dfd,stroke:#0a0
    style Z fill:#dfd,stroke:#0a0

Price comparison for .org domains for 1 year (as of May 2026):

Cloudflare sells domains at cost price. Its revenue source comes from other services (Workers, Stream, Enterprise). For one-person operators like I, the cheapest + renewal cost is stable.

3. Why Choose Cloudflare — Integrated Value

Star Whale would ultimately utilize Cloudflare Tunnel + DNS + WAF + (later) Email Routing. If the domain is purchased elsewhere, an additional task of transferring nameservers to Cloudflare is needed. Purchasing from the same place automates that step.

4. Purchase Process — 5 Minutes

1. dash.cloudflare.com → Domains → Buy domain
2. Search sticknstone → Select .org
3. Enter registrant information (name, email, address)
   – WHOIS is automatically masked (anonymously like Contact Privacy Inc.)
4. Card payment ($10.44)
5. Immediately activated. Nameserver automatically points to Cloudflare

If purchased from another registrar, changing the nameserver to Cloudflare takes an additional step (24-48 hours for propagation). Purchasing from Cloudflare negates that time.

5. Caveats

Caveat 1. 60-day Transfer Lock

For 60 days after domain registration, transfer to another registrar is not permitted (ICANN rule). If there’s no immediate need to transfer it to somewhere other than Cloudflare, it’s irrelevant.

Caveat 2. WHOIS Privacy

Domain registrant information is usually public. Name, email, address, and phone are registered on the WHOIS DB. Cloudflare automatically masks this (other registrars charge around $5-$10/year for this option). Email is displayed as an anonymous address like [email protected].

Caveat 3. Changing Payment Card

Automatic renewal fails if the card expires/changes → domain expiration → 30-day grace period → Recovery. Anyone can take it back. Updating Cloudflare payment information is essential when changing the card.

Caveat 4. Domain Price Fluctuation

While Cloudflare’s pricing has little variability due to cost price, new TLDs (.io, .dev, .app) increase slightly each year. .org, .com, and .net remain stable.

Caveat 5. If the Site Goes Down?

Even if the mini-PC fails or cloudflared terminates, the domain itself remains owned by I. The DNS records remain alive in the Cloudflare dashboard. If the mini-PC is restored, it will function again.

FAQ

Q. Is .org better? What about .com?
.com is the most common, but good names are mostly taken. .org feels natural for non-profits and personal notes. There is almost no SEO difference (per Google’s official statement).

Q. What about Korean domains (별고래.한국)?
Possible. However, it is difficult for foreigners to input + some compatibility issues with certain tools + lacks trust. A combination of English domain and Korean content is standard.

Q. What about bundled products (Gabia HostingNW, etc.)?
For one-person self-hosting mini-PC, it’s irrelevant. Hosting in bundled products usually means shared hosting (sharing the server with others). Less control.

Q. How does Cloudflare Email Routing work?
[email protected] → Cloudflare receives → forwards to my personal email ([email protected]). Free unlimited. Separate SMTP is needed for sending (Resend·Mailgun free tier).

Q. Can I trust domain valuation sites (Estibot, etc.)?
For a one-person operation, it’s irrelevant. The use value of a domain (is it good for me?) is more crucial than market value (who would buy it).

Next Episode Preview

Part 7 — It’s Complicated: Naming the Site. Three days’ worth of contemplation and decisions on the English subtitle after changing “Jam Jam’s Voyage Diary” to “Star Whale.”

One-Line Summary

Purchasing a domain is a lifelong decision. Cloudflare Registrar = cost price + DNS + Tunnel + Email + WHOIS protection integrated in one account. .org costs $10.44 per year. Half the price compared to Gabia.
“`