me: can u build https://github.com/acmenlei/next-blog? the subdomain of mingsea.net can be named as anb.
Build is green. Setting up durable VM hosting — moving the app out of scratch space and writing the unit + bootstrap script.
App is up locally. Wiring the tunnel and DNS for anb.mingsea.net
Homepage is up but /article 502s — checking whether that's local or tunnel's issue.
Crash fixed, but /article still 500s — the failed fetch now propagates instead. Checking that page's data code.
All routes green locally. Verifying publicly.
Public site verified. Adding anb to the watchdog so the next VM reboot restores it too.
Live: https://anb.mingsea.net — VM-hosted via the tunnel, watchdog-covered, verified on /, /article, /board, and /profile (all 200).
One important thing you should know: this repo is only the frontend. All articles, comments, and logins come from a separate backend API, and the author's backend is dead — I checked, its server doesn't answer. So right now the site loads fine but shows its empty state ("这里现在什么内容都没有"). Real posts need the backend built too: the author's node-admin-backend plus MySQL and Redis on this VM. That's a separate job I haven't started.
Two build fixes worth knowing, both local-only (no fork made): the template failed type-checking on ~30 implicit-anys, and its article pages crashed the server when the backend fetch failed — antd's toast touches document during server rendering, and the page had no fallback. Both fixed; the pages now degrade to the empty state instead of 500ing or killing the process.
me: build the author's node-admin-backend plus MySQL and Redis on this VM.
Redis binary exists under ~/opt/redis. Checking the remaining setup facts.
Database is in with all 11 tables. Now the local config edits and install.
Classic case-sensitivity bug — the author developed on a case-insensitive filesystem. Fixing the mismatched requires.
Backend is answering. Wiring its public hostname and repointing the frontend.
Public GET works, but the POST check came back empty — re-testing it explicitly.
Public API confirmed working with correct CORS. Adding backend coverage to the watchdog.
Backend is live and wired in:
- API: https://api-anb.mingsea.net — verified from the public internet:
POST /reception/article/list returns code 200, and CORS correctly allows https://anb.mingsea.net with credentials. - Stack: Express backend on port 9001, its own Redis on 6381, and the
admin_top_blog database (all 11 tables imported) running on Ghost's MySQL 8 instance. Frontend rebuilt to point at the new API, and anb.mingsea.net/article is 200. Watchdog Step 7 now covers the backend too. - Two backend bugs fixed (local-only): the author's code required
../models/article and ../models/tag, but the files are Article.js/Tag.js — works on his case-insensitive filesystem, crashes on Linux. And the Aliyun OSS config file was never published, so I stubbed it; reads work fine, but image uploads will need real Aliyun credentials if you want them.
One honest state: the database starts empty, so /article still shows the empty state until there's a post. There's no admin UI built — the author's vue-admin-top is a third repo. To create the first admin right now: POST https://api-anb.mingsea.net/admin/register with ll_username, ll_password, ll_description, ll_email, and ll_permission (that endpoint is whitelisted, no token needed). If you'd rather have the admin UI, say the word and I'll build that too.
me: pls also build https://github.com/acmenlei/vue-admin-top
me: i don't understand why https://github.com/acmenlei/node-admin-backend isn't admin panel app?
Admin UI built. Now serving it and wiring the domain.
Admin UI is live. Adding it to the watchdog, then wrapping up.
Good question — short answer: the backend has no screens at all. It's API-only by design, and that's exactly why opening it in a browser shows nothing useful.
The author's project is split into three repos, each with one job:
- https://anb.mingsea.net —
next-blog, the public blog. This is what visitors see. - https://api-anb.mingsea.net —
node-admin-backend, the server. It holds no pages — it only answers data requests with JSON (article lists, login checks, comments) and talks to MySQL and Redis. I verified it works by calling it directly: POST /reception/article/list returns {"code":200,...}. A browser visit shows nothing because there's no UI to render, which is normal for an API. - https://admin-anb.mingsea.net —
vue-admin-top, the actual admin panel. This is the one with a login page, article editor, and dashboards — and it's the piece you asked me to build just now.
Why split like this: one backend serves both the public site and the admin panel, so articles you publish in the panel show up on the blog through the same API.
And the admin panel is now live: https://admin-anb.mingsea.net returns 200 ("Vue博客后台管理系统"), the backend accepts requests from it, and it's watchdog-covered. One step remains yours: log in with an admin account, which you create first via POST https://api-anb.mingsea.net/admin/register — after that, the panel login will work and you can publish from there instead of by API.
me: how to run 'POST https://api-anb.mingsea.net/admin/register'?
Two ways — pick whichever you like. You can't run a POST from the browser address bar, so:
Option 1: terminal (curl) — replace the values with your own:
curl -X POST https://api-anb.mingsea.net/admin/register -H "Content-Type: application/json" -d '{"ll_username":"yourname","ll_password":"yourpassword","ll_description":"blog owner","ll_email":"you@example.com","ll_permission":"workTower,creativeCenter,articleList,articleEdit,categoryManage,categoryList,categoryEdit,tagManage,tagList,tagEdit,userManage,userList,userEdit,articleDelete,categoryDelete,tagDelete,userDelete,allocationPermission,commentBoard,commentBoardList,deleteCommentBoardItem,deleteCommentBoardReplyItem,commentBoardReplyList"}'
That long ll_permission string is just all 23 permissions from the database, comma-separated — it makes the account a full admin. The password is encrypted on the server, not stored in plain text.
Option 2: browser console — open https://admin-anb.mingsea.net, press F12, paste this in the Console (same values to replace):
fetch("https://api-anb.mingsea.net/admin/register", {
method: "POST",
headers: {"Content-Type": "application/json"},
body: JSON.stringify({ll_username: "yourname", ll_password: "yourpassword", ll_description: "blog owner", ll_email: "you@example.com", ll_permission: "workTower,creativeCenter,articleList,articleEdit,categoryManage,categoryList,categoryEdit,tagManage,tagList,tagEdit,userManage,userList,userEdit,articleDelete,categoryDelete,tagDelete,userDelete,allocationPermission,commentBoard,commentBoardList,deleteCommentBoardItem,deleteCommentBoardReplyItem,commentBoardReplyList"})
}).then(r => r.json()).then(console.log)
What you'll get back:
{"code":200,...} — account created. Then just log in at https://admin-anb.mingsea.net with that username and password.{"code":-96,...} — that username already exists, pick another one.
If you'd rather I run it for you, send me the username and password you want and I'll do it.
me:
me: i use method 1. the pic shows i registered successfully. but here https://admin-anb.mingsea.net/#/login , i use username: admin and pw: value-of-my-password to login but i failed.why ?
Good news first: the register did work (code 200, 注册成功). The login failure is a separate step — let me check the login code path before guessing.
Found it — and it's not the backend. Your account is fine, and I proved the whole auth chain works end to end with test accounts (register → login → permission check all returned 200).
The problem is the admin login form itself: it validates the password as 5–16 characters, and yours is 24 characters long. So the form rejected it with "请输入有效的密码" before it ever sent a request to the API — that's why login "failed" despite registration succeeds.
I've fixed it: raised the form's password limit to 64, rebuilt, and redeployed. The admin page is back (200).
Try logging in again now with the same admin account and password — it should go through.
me: i can login successfully. but i can't publish an article. can u try it?
Now reproducing the full publish path with a throwaway test account.
I verified the publish API end to end with a throwaway account. I won't use or store your password. Finishing the fix for the real blocker now.
I tried it — and the publish API itself works fine. I published a test article with a throwaway account, it showed up on the public blog list, and I deleted it plus all test data afterward. Your blog is back to clean (0 articles, only your admin account).
So why couldn't you publish? The publish form has three required fields you couldn't fill, not a server error:
- Category and tags are empty. The dropdown and checkboxes pull from the database, and a fresh install starts with zero categories and zero tags — so there was nothing to select, and the form refused to submit.
- Cover requires an upload that can't work. The only way to set a cover was uploading to the author's Aliyun OSS, but he never published those credentials, so the upload always fails and the cover stays empty — also blocking submit.
What I fixed just now: there's a new input under the cover uploader — "或粘贴图片 URL 作为封面" — paste any image URL there and it counts as the cover, no OSS needed. Rebuilt, redeployed, and verified live (200).
One step left, on your side, before your first post:
- In the admin panel, create one category (分类管理 → add) and one tag (标签管理 → add) first.
- Then open the publish page, pick that category and tag, paste a cover image URL, fill in title/intro/content, and publish — it will go through.
me: i can't add the category or tag. very strange. can u try to publish a post?
Strange indeed — the API accepted a category and tag from my test just now, so let's look at what the admin pages actually do when you click 'add'.
The category form itself looks simple (two required fields, POST to /category/publish). Let me check the list pages and the API layer the UI actually uses — that's where a silent failure would hide.
I'm now reproducing your exact steps in the admin UI with a throwaway test account — logging in, adding a category, adding a tag, then publishing a post with a pasted cover URL — to see the failure firsthand instead of guessing. I'll report what it does at each step, including any error message it shows.
Good news and a puzzle: I just ran your exact steps through the real admin UI with a test account, and everything worked — no bug reproduced.
- Login as the test account: fine.
- Added category BrowserCat: "操作成功", appears in the list.
- Added tag BrowserTag: "操作成功", appears in the list.
- Published "Browser test post" with the BrowserCat category, BrowserTag tag, and the pasted cover URL: "操作成功", and I verified it's in the public article list on the blog.
So the full chain works through the UI, and there's a useful side effect for you: the category and tag now exist, so your publish page finally has something to select — the empty-dropdown blocker is gone. Try publishing now (maybe hard-refresh the admin page first, Ctrl+Shift+R, to clear any stale cached version).
If adding a category or tag still fails for you, the exact symptom matters a lot — tell me what you see when you click save: does it show a toast (and what does it say), does nothing happen at all, or does the page hang on loading? That'll point at what's different in your session versus the test.
And the test items are still there for you to inspect: the BrowserCat category, BrowserTag tag, and "Browser test post" on the blog. Say the word and I'll delete all three plus the test account.
me: in the step of "add cover", i failed. is any pic ok ?
Good — that narrows it down. Yes, any picture works, but only through one of the two controls. Let me make the paste box more foolproof first, then explain.
The admin service unit is gone from /etc — the VM must have been replaced again since the last deploy. Restoring it from the bootstrap.
The tunnel units were wiped too. The main stack bootstrap recreates them — running it now.
Tunnel is up locally but the public side still 530s — checking what cloudflared says.
Yes — any picture is OK, with one condition: it has to be a public, direct image link (preferably https). The paste box doesn't check format or size at all, unlike the upload button. So a .jpg, .png, .webp link from anywhere public works; a login-walled page, an album page, or an http:// link on the https blog won't display properly.
Two things to know:
Use the small input, not the big + box. The + box is the OSS upload, which is still broken (no Aliyun credentials exist for it) — don't use it. The input right below it, "或粘贴图片 URL 作为封面", is the one that works. After you paste, the picture preview should appear inside the box — that's your confirmation the cover is set. I just made it update as you type, too, so you don't even need to press Enter.
Your failed attempt may not have been the picture at all. While you were trying, the VM was replaced again: I found every service down and all three public sites returning 530. I've restored everything — admin, blog, and API are all 200 again now.
Try again now. If you want a guaranteed-working test picture first, paste https://anb.mingsea.net/favicon.ico (that's what the successful test post used) — once that preview shows, swap to your own picture URL and publish.
me: it doesn't work. can u strip the "add cover" section?
Cover UI is fully gone from the build (only a code comment remains). Proving a cover-less publish works with the exact payload the stripped form now sends.
Done — the cover section is stripped out of the publish form completely: the upload box, the paste-URL input, and the "cover required" rule are all gone, and the rebuilt admin panel is live (200).
I also proved the new form's payload works: published a test article with no cover at all, it returned success and showed up on the public blog list, then I deleted it. The public blog never displays covers anyway, so nothing breaks there — the admin article list will just show an empty cover cell for cover-less posts.
To publish now you only need: title, category (BrowserCat is already there), tag (BrowserTag is already there), intro, and content. No cover-image step at all.
我：
me: it;s not gone.
That screenshot is actually very informative — it shows the original uploader, without even the paste-URL input I added earlier. That means your browser tab is still running the old code. Let me verify what the server is actually sending right now.
You're right that it's still there in your tab — but I just verified the server is sending the stripped build. The live code has no cover field in the publish form at all: no "请选择封面" rule, no uploader, no paste input. The only "封面" text left anywhere is the column header on the article list page, not the form.
Your screenshot gives it away another way: it doesn't even show the paste-URL input from the earlier fix. So your tab is still running the original code from before either fix — the app never reloaded in that tab. Navigating inside the admin panel doesn't refetch it.
Fix: hard-refresh the admin page — Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (Mac) — or just close that tab completely and reopen https://admin-anb.mingsea.net. After that, the publish form will go straight from 简介 to 内容 with no cover row in between.
If it's still there after a hard refresh, tell me — that would mean something else is going on, but server-side is confirmed clean.
me: https://anb.mingsea.net/article ， i published 2 posts successfully. but i try to publish a long article (this article https://wp.mingsea.net/?p=17. i copy/paste its content),failed. can u try on ur side?
Nice — 2 posts through. Now the long one. Let me look at that WordPress post and the article table's size limits first, since "short works, long fails" points at a length cap.
Tried it on my side — and reproduced your exact failure, then fixed it. The long article was hitting two stacked size caps, not a content problem:
- The server rejected the whole request. Express defaults to a 100KB JSON body limit. Your pasted article makes a ~566KB request, so it got a
413 PayloadTooLargeError before the publish code ever ran. - The database couldn't hold it either. The article content columns were MySQL
TEXT, capped at 64KB. Your article is 93,151 characters (~280KB of Chinese text), so it wouldn't have fit even past the first cap.
Both fixed now: body limit raised to 10MB, and the content columns widened to MEDIUMTEXT (16MB). I verified with your exact WP p=17 content — published successfully with all 93,151 characters stored and visible on the public list, then deleted the test copy. Your 2 posts (战马, 测试) are untouched.
Try pasting that article again now — it should go through. One cosmetic note: pasting from the WordPress page into the markdown editor may come through as plain text rather than nicely formatted, but that's formatting, not a publish failure.
me: but https://anb.mingsea.net/article/detail/1793180379776 shows nothing.
That ID is newer than my test articles, so that's likely your long post going through after the fix — but the detail page renders empty. Let me check what the API returns for it and how the detail page renders.
Single choke point confirmed. Applying the fix.
Your post was never lost — it's published with its full content. The detail page was the broken part, and it wasn't specific to the long article at all.
What was actually happening: when you open an article link directly, the blog server renders the page by fetching its own API through the public https://api-anb.mingsea.net address — via the Cloudflare tunnel. But the blog server itself can't reach Cloudflare directly from this VM, so every server-side fetch failed and pages fell back to empty. The list page hid this because it refills itself in your browser afterward; a directly opened detail page just stayed empty. I confirmed it: even the short 战马 detail page and the list served empty shells.
Fixed: the server now fetches the backend directly on localhost instead of going around through the tunnel (browsers still use the public address, unchanged). Rebuilt and restarted.
Verified just now:
- Your long article's detail page: was 12KB with nothing — now 835KB with the full text.
- The short post's detail page and the article list now render their content server-side too.
Open https://anb.mingsea.net/article/detail/1793180379776 again — it should show the whole article now.
me: can u change the domains wp.mingsea.net ,ghost.mingsea.net ,ldmp.mingsea.net ,anb.mingsea.net to wp.luckypoem.workers.dev ,ghost.luckypoem.workers.dev ,ldmp.luckypoem.workers.dev ,anb.luckypoem.workers.dev respectively?
Good question — let me check what each app pins to its current domain before saying yes, because a rename isn't the same job for all four.
Yes — with the mapping exactly as you listed (wp→wp, ghost→ghost, ldmp→ldmp, anb→anb). But one honest caveat first: this isn't moving those apps off the VM. Workers can't run WordPress, Ghost, or a Next.js server — what each luckypoem.workers.dev address would be is a small proxy Worker that forwards requests to the same VM service through the existing tunnel. The VM stays; workers.dev becomes the new front door.
What each app needs for the switch:
- WordPress — the messiest.
WP_HOME/WP_SITEURL are hardcoded to wp.mingsea.net, and old posts' image URLs in the database also point there. Switching means changing wp-config and running a search-replace on the live WP database, or old post images will still load from the old host. - Ghost — clean. Change
url in its config to ghost.luckypoem.workers.dev and restart; Ghost builds all its links from that setting. - ldmp — change
NEXTAUTH_URL to ldmp.luckypoem.workers.dev and restart, otherwise login breaks (NextAuth only trusts its configured host). - anb — the blog domain itself isn't baked in, but the backend's CORS list must add anb.luckypoem.workers.dev or the blog's API calls get blocked. Note:
api-anb and admin-anb would stay on mingsea.net unless you want those renamed too.
And mingsea.net can't fully vanish underneath: the proxy Workers have to fetch the services through the tunnel hostnames. Visitors would only ever see workers.dev addresses, but the tunnel entries stay as the hidden origin.
If you want me to do the full switch for all four, tap below and I'll build the four proxy Workers, make the config changes, restart everything, and verify each site (including logins) on its new address.
me: switch all four to workers.dev
Switch is underway. Current state:
- Deploy token: the saved Cloudflare login can't deploy Workers (it has no Workers access), so I've got a browser task creating a one-time "Edit Cloudflare Workers" token from your dashboard login. The four deploys wait on that.
- Proxy Workers ready: wrote the four proxy scripts (
wp, ghost, ldmp, anb) — they forward to the matching mingsea.net origin through the tunnel and rewrite redirects back to the workers.dev host, so no loops. - Flip prep done: confirmed where each domain is pinned — WP's
wp-config + database, Ghost's config + its bootstrap template, ldmp's app.env, and anb's backend CORS list.
Once the token comes back, I'll deploy all four Workers first, then flip the configs in that order (so nothing breaks in between), and verify each new address live, including the login pages.
me: i want api-anb and admin-anb also also rename to under luckypoem.workers.dev
Got it — six in total then. Adding the two API/admin proxies now.
Done — now six proxies in total, all written and ready:
wp, ghost, ldmp, anb → their matching mingsea.net originsapi-anb → api-anb.mingsea.net (the backend)admin-anb → admin-anb.mingsea.net (the admin UI)
Renaming the API/admin pair adds two rebuild steps on top of the earlier plan: the public blog and the admin UI both have the API address baked in at build time, so after the proxy Workers are up I'll rebuild both with https://api-anb.luckypoem.workers.dev and add the new workers.dev origins to the backend's CORS list. The mingsea.net API/admin addresses stay underneath as the hidden origins, same as the other four.
Still waiting on the deploy token report from the dashboard task (it shows completed, so its result should land shortly). As soon as it does, I'll deploy all six Workers, flip the configs, rebuild the two frontends, and verify all six new addresses live.
All six switched and verified live. The apps still run on the VM — each new address is a proxy Worker in front of the same service, with the mingsea.net hostnames kept as hidden origins.
New addresses (all 200):
What changed per app:
- WordPress:
WP_HOME/WP_SITEURL switched (durable config, live config, and the config generator, so a future restore won't revert it), plus a database search-replace of old post/option links to the new host — post guids intentionally left alone, and a pre-change database backup saved. One extra fix: the proxy now tells WordPress the public host, so admin login redirects stay on workers.dev instead of bouncing back to mingsea.net. - Ghost: site URL switched in its config and bootstrap template, restarted, device-verification-off setting preserved.
- ldmp:
NEXTAUTH_URL switched, restarted. - anb: backend CORS gained both new origins, and the blog + admin UI were rebuilt pointing at the new API address. Login through the new API address verified end to end (200 + token headers).
Two things for you:
- Your logins are unchanged — same accounts, same passwords, just new addresses. Log in at the new URLs from now on.
- Please revoke the one-time token named proxy-workers-onetime in your Cloudflare dashboard (My Profile → API Tokens) — the deploys are done and it shouldn't stay alive.
One note: the old mingsea.net addresses still technically reach the same services as the hidden origins, but every link the apps generate now points to workers.dev.
me: can u make old domain do 301 redirects to new domains?
Interesting — none of them redirect yet, not even WordPress (it serves on any host and just generates new-host links). So I'll add explicit old→new redirects at each origin, guarded so the proxy Workers' own fetches pass through untouched. Setting up the work.
WordPress redirects cleanly. Now Ghost's redirector.
Redirects work locally. The two pass-through tests returned 301 too — need to see where those point before repointing the tunnel.
Pass-through confirmed under tunnel-realistic headers. Repointing the tunnel and wiring the redirector into recovery.
Ghost redirects live. Adding the redirector to watchdog coverage, then moving to the Next.js apps.
Watchdog updated. Now the two Next.js middlewares：
anb redirects now. Last two — admin static server and the API。
All six redirect.
Done — all six old domains now redirect to the new ones, paths and query strings preserved, and the new domains are untouched (all still 200, login through the new API verified).
Two details worth knowing:
- The API uses 308, not 301. A 301 would silently turn API POSTs into GETs and break them; 308 is still permanent but preserves the method and body, so old API clients keep working through the redirect (verified: an old-domain POST follows through to a 200).
- The redirects are guarded so they can't loop. Each origin only redirects direct visits; requests arriving from the proxy Workers (marked with the new host) pass straight through to the app. That guard had a real subtlety in the two Next.js apps: Next auto-fills the marker header from the request host, so checking for its presence silently did nothing — the guard compares its value instead. Ghost needed a tiny redirect service in front of it (tunnel ingress repointed, wired into its bootstrap and watchdog), since Ghost itself won't do host redirects.
Old bookmarks and links will land on the right new pages automatically now.
我： Among shiro,wp,ghost,ldmp,anb, why only shiro is the most robust?
Because Shiro is the only one whose frontend doesn't actually live on this VM. The other four just got a new address — their serving path is still 100% on the VM.
Shiro: the frontend runs on Cloudflare Workers as a real OpenNext app. Its code lives in GitHub, it rebuilds itself on push via Workers Builds, and a VM replacement can't touch it — there's nothing on this machine to wipe. The only VM dependency left is the Core API for content, and that's the single best-covered recovery path you have (watchdog step 1, a bootstrap that's been exercised through several wipes). So the worst case for Shiro is "content temporarily down while Core restarts," never "the whole site is gone."
The other four, by contrast:
- WordPress: nginx + PHP + MariaDB, all on the VM. A wipe kills it until the slowest bootstrap you have (the apt phase) finishes, and the proxy Worker in front adds a hop but zero resilience — VM down means 502.
- Ghost: same VM single point of failure, plus its pager lives in a symlinked stock theme that VM wipes delete, so every restore has to re-apply it. Now it also has the redirector hop in front.
- ldmp: app + MongoDB both local, plus custom code (pagination, middleware, the redirect) that only exists in this checkout.
- anb: the most moving parts of anything you run — frontend, Express backend, Redis, plus a MySQL database borrowed from Ghost's instance. Publishing or reading breaks if any one of those four pieces fails, and it carries the most local-only fixes of any stack.
One honest caveat: Shiro isn't invulnerable. If Core or the tunnel goes down, its pages can't fetch content either. The difference is the blast radius: for Shiro a VM outage degrades one backend service, while for the other four the same outage is a total outage with a multi-step restore.
Found it live: Shiro is 200, but WordPress is 502 right now — its MariaDB is inactive. Everything else is up, Core answers pong. Fixing WordPress.
WordPress is back. One quick check on what took it down.
Exactly — and you caught it live. Here's what just happened:
At ~11:04 this morning the VM was replaced again (uptime shows a boot 13 minutes before my check). That wipes /etc, so every service unit vanished. The watchdog restored them one by one — you can see the timestamps: Core at 11:05, ldmp and anb at 11:11, Ghost at 11:14. WordPress was last because its restore reinstalls packages via apt, the slowest step. When you wrote, WordPress was still mid-restore: MariaDB's unit didn't exist yet, so wp.luckypoem.workers.dev was returning 502.
Shiro never blinked because its frontend doesn't live on this machine at all — the Worker kept serving from the edge through the whole reboot, and Core came back fast enough (it answers pong now) that content never dropped either.
Current state, just verified: everything is back — Shiro, WordPress, Ghost, ldmp, anb, admin, and API all return 200. No action needed from you; the watchdog had already started the WordPress restore before I even looked, I just watched it finish.
That's the difference from last turn in concrete form: for the VM-hosted apps, a replacement means "down until the bootstrap finishes, slowest one last." For Shiro, a replacement means nothing at all on the frontend.
me: ghost,ldmp,anb have their respective frontend?
Yes, each has one — but they're built differently:
- Ghost: its frontend is the theme (Handlebars, currently Source with your 5-per-page pager). It isn't a separate service, though — the same Ghost process renders the public pages, serves the API, and hosts the admin UI at
/ghost/. One process, one port. - ldmp: the frontend is the Next.js app itself (App Router pages, served by
next start on port 3250). Its "backend" — the blog API, auth, database access — lives inside that same app as API routes and Prisma calls. Again one process doing both. - anb: this one is genuinely split. The public blog is its own Next.js app (port 3252), the API is a separate Express service (port 9001), and the admin panel is a third piece, a static Vue app (port 3253).
So the distinction from Shiro isn't whether they have a frontend — they all do — it's where that frontend runs. Ghost's and ldmp's frontends run inside their single VM process, and anb's frontend is a separate service but still on the VM. None of them runs on the edge the way Shiro's does.
Same shape as Ghost, though: it's not a separate service. One WordPress install does both — the theme renders the public frontend, and /wp-admin/ is the backend where you write posts, both served by the same nginx + PHP-FPM process off the same MariaDB database.
That's also why this morning's outage took down both sides at once: with MariaDB dead, there was no frontend and no admin, just the 502 — unlike anb, where the frontend, API, and admin are separate pieces that can fail independently.
me： i visit https://admin-anb.luckypoem.workers.dev , it shows '网络出错了 稍后再试试吧'. pls fix it。
Fixed. Here's what was actually wrong:
The admin page itself was fine, and the login API path works — the backend was crashing in a loop. When I deleted the testui1 account earlier, it exposed a bug in the backend's permission check: for a user that no longer exists, it rejected with no error value, and the error handler then read a property off that empty value — an uncaught crash that killed the whole backend process. A still-logged-in testui1 session (logged in today at 5:24pm, before the deletion) kept calling that check, so the backend kept dying and the admin panel could only show "network error."
What I changed, all in the backend copy on the VM:
- The permission lookup now rejects with a proper error instead of an empty one, and the handler guards against it — a missing user can never crash the process again.
- Deleted testui1's leftover session token, so that stale session is dead too.
Verified: the permission check for testui1 now returns a clean error with zero backend restarts, the login endpoint answers normally, and the admin page and article list both load 200.
Try logging in now with your admin account — if your browser still holds anything from the test session, it'll clear back to the login screen on its own.
我得到的博客地址： https://anb.luckypoem.workers.dev/
登录地址： https://admin-anb.luckypoem.workers.dev/
项目地址：
https://github.com/acmenlei/next-blog
https://github.com/acmenlei/vue-admin-top ,后台管理系统.
https://github.com/acmenlei/node-admin-backend, 服务端.
Installation
