A Guided Tour of This Site

Full disclosure up front: this is a fleet of sites run by one person. One VPS, one domain — tianli.cyou — carrying a main site, a knowledge base, a hydro toolbox, and a pile of things only I ever use. In July 2026 it went through two events: a redesign called "paper manual," and a rather thorough spring cleaning. Now that the dust has settled, here is a guided tour — what's here, what changed, what got deleted, and how the "for my eyes only" entrances are designed.

What's here

Three things are public:

Three things are not: a scheduled-jobs panel, a VPS ops console, and a personal loan calculator. How they hide and how I get in — that comes later.

The redesign: a paper manual

The design language of this redesign is called "paper manual": a light paper background, body text first, restrained navigation — the whole site reads like a well-bound technical manual rather than a landing page glowing with gradients. Bilingual, with an English mirror for every piece of content.

The most important cut of the redesign wasn't an addition — it was navigation. The top bar used to carry an "Apps" mega dropdown listing a dozen subsites by category. That was a relic of the old station-cluster architecture; half of those domains no longer even had DNS records. Now the entire top bar holds exactly two things: a name, and a language switcher.

The other cut hit the homepage stats: it used to say "6+ production subsites," half of which were dead. Now it says 3, and it really is 3.

Spring cleaning: keep the living, delete the dead

The redesign came with a full autopsy. One principle only: every deletion must have measured evidence — domains checked against authoritative DoH answers, services probed with curl, processes read from systemd journals and docker ps. Only what was provably dead got touched, everything was backed up first, and rollback is a single command.

What turned up was more than expected:

• 3 whole sites: an ops dashboard, a document-tools site, a mind-map site — code, routes, and access policies removed end to end
• 5 zombie runtimes: a monitoring container that ran bare for 12 days after its domain was deleted, reachable by no one; a service announced as retired in the last cleanup but never actually stopped; a message pusher with three months of zero journal output
• 6 Cloudflare Access applications: every entrance they guarded no longer existed
• assorted cron jobs and config entities pointing at dead targets

The most ironic thing about zombie services: they don't error. CPU stays low, logs stay clean, monitoring stays green — it's just that no one needs them. Infrastructure debt isn't the stuff that breaks. It's the stuff nobody remembers why it's still on.

The private entrance: designing for one bookmark

Plenty of things in this fleet are for my eyes only: the ops console, the scheduled-jobs panel, a few personal tools. Their design follows three rules:

1. Public/private layering: public content has zero gate; private tools all sit behind Cloudflare Access — email one-time code, Zero Trust.
2. Never expose IP:port: every service goes subdomain + HTTPS + CF proxy; origin ports are invisible to the public internet.
3. A single bookmark: the private entrance requires remembering exactly one thing — the console. Inside, a row of "quick links" at the top reaches every other site.

The payoff is symmetric: externally, the attack surface collapses to one layer — the Cloudflare edge; internally, the cognitive load collapses to one bookmark. Before the redesign I couldn't even list all my own private entrances — which was itself the signal that things needed deleting.

(A few more-private paths — subscription-type things — run on separate routes and aren't covered here.)

How one person maintains a fleet of sites

Finally, method. Managing a fleet alone isn't about diligence — it's about making drift structurally impossible:

• Menus as a database: every subdomain, group, and navigation relation is defined in a set of YAML entities; the navbar, service lists, and nginx config are all generated from it. Change one place, everything syncs; 15 classes of drift audits hang on pre-commit, so mismatched config can't even be committed.
• Deploys as verification: the deploy script does more than sync files — build fingerprints are compared against production, the CDN cache is actively purged, and 404s are prechecked before going live. "Deployed successfully" is verified, not felt.
• Deletion as backup: every cleanup lands a backup before touching anything; one command undoes a mistake. You can only delete boldly if you can restore instantly.

This site will keep growing, but the direction is set: content grows a lot, infrastructure grows a little. Come have a look around.