Troubleshooting·5 min read·

I'm getting 404 errors in admin after a deploy

Next.js build cache, Railway deploy rollback flow, force-dynamic routes, and hard refresh — diagnose post-deploy 404 errors in the VeloCMS admin panel.

You pushed a new deploy to Railway and now certain admin pages return 404. The blog's public routes are fine, but admin routes are broken. This is almost always a Next.js cache or deployment timing issue — nothing is actually deleted.

Hard refresh first

Before diving into Railway logs, try a hard refresh on the 404 page. Press Ctrl+Shift+R on Windows/Linux or Cmd+Shift+R on Mac. This tells the browser to ignore its cached HTML and JS and fetch fresh versions from the server. Most post-deploy 404s that affect only your browser (not all users) resolve this way.

If the hard refresh works for you but a colleague still sees a 404, they may have the old JS bundle cached. Admin routes load JavaScript chunks by content hash — after a deploy, the new chunks have new hashes and the old cached chunks return 404. Hard refresh for them too.

Next.js cache after deploy

Railway's build process for VeloCMS runs npm run build, which outputs the Next.js build to .next/. Between deploys, Railway keeps a build cache layer. In rare cases, a partial cache from a previous build can conflict with the new build output — particularly for dynamically generated admin routes that use cookies() or headers(). The symptom is a 404 on routes that definitely exist in the source code.

  • Go to the Railway dashboard → your VeloCMS service → Deployments tab.
  • Find the current deployment and click the three-dot menu → Rebuild (not Redeploy).
  • Rebuild discards the build cache and builds from scratch. It takes 3–5 minutes instead of the usual 1–2.
  • Once the new deployment is active, test the 404 route again.

Force-dynamic route misconfiguration

Admin routes in VeloCMS use export const dynamic = 'force-dynamic' to prevent static caching — admin content changes frequently and must always be fresh. If this directive is missing from a new route you added, Next.js may try to statically prerender it at build time. If that static render fails (for example, because it tries to read cookies() during the build), Next.js records the route as a prerender failure and falls back to a 404 at runtime.

// Every admin page.tsx must include this at the top:
export const dynamic = "force-dynamic";

// Without this, Next.js attempts static generation,
// which fails for pages that read cookies/session.

Check that any new admin route files you added have this export. It belongs at the top of the page.tsx file, outside of any function.

Railway rollback flow

If the 404 is affecting all admin users (not just your browser), and you need to restore service immediately while you debug, Railway makes rollback simple. Go to Railway dashboard → Deployments → find the last working deployment → click Promote to Active. This makes the previous deployment live again within 30 seconds, without a new build.

A rollback restores the previous code but keeps the current database state. If the deploy that broke admin routes also included a PocketBase schema migration, rolling back the code without rolling back the migration can create a mismatch. If your deploy included migrations, fix the code issue forward rather than rolling back.