A Forgejo Webhook-triggered automated deployment pipeline is now configured:
Developer pushes code to the main branch
Forgejo triggers a webhook to notify the production server
The server automatically pulls the latest code, builds a new container image, and replaces the running container
Automatic health checks verify service availability, followed by cleanup of obsolete images
The entire process is fully automated—“push-to-deploy”—with full traceability of deployment logs.
Issues Resolved During Deployment
Container Network Connectivity: Adjusted firewall policies and DNS configurations to ensure network reachability during both container build and runtime
Database Initialization: Resolved compatibility issues with Drizzle ORM migration files
Dependency Synchronization: Fixed build failures caused by inconsistencies between lock files and dependency versions
Operations documentation has been archived; future iterations will be deployed automatically via Git pushes.
Investigation confirmed this was a brief interruption during deployment rebuild—not a routing configuration issue. The /login route functions correctly inside the container (HTTP 200), and the nginx reverse-proxy configuration (location /) forwards all paths to port 4000 without omission.
Current status:
https://app.windfonts.com/login → HTTP 200 ✓
https://app.windfonts.com/ → HTTP 200 ✓
Webhook-Based Automatic Deployment Verified
A full deployment pipeline was successfully triggered by simulating a Forgejo webhook, confirming end-to-end functionality:
Swap → Stop old container → Start new container → Health check passes within 15 seconds.
Cleanup → Automatic podman image prune.
Deployment logs confirm: [ok] deploy success, health check passed.
Additionally, Forgejo git push credentials have been configured on the cravatar-prod server, enabling direct code pushes from the server going forward.
The podman run command in the deployment script was missing the --env-file parameter, causing authentication-related environment variables (e.g., admin credentials, NextAuth secret) to be omitted from the container. As a result, the container used only the default values hardcoded in the Dockerfile, preventing the authentication module from functioning correctly.
Fix: Added the --env-file parameter to the deployment script. After rebuilding the container, login verification at the API layer succeeded.
Issue 2: Browser-Side Server Action Error
During login, the browser console displayed UnrecognizedActionError: Server Action was not found, and the POST request returned HTTP 404.
Root Cause: A bug exists in Next.js 16’s Turbopack standalone build — the node and edge fields in server-reference-manifest.json are empty objects, preventing Server Actions from being registered. We attempted building with --webpack, which generated a correct manifest, but runtime native modules were missing.
Final Resolution: Upstream has migrated the login logic from Server Actions to the NextAuth credentials provider, routing authentication through the API route (/api/auth/callback/credentials). This fully bypasses Turbopack’s Server Action registration issue. After rebuilding and redeploying, login functionality was restored.
A hard browser refresh confirmed successful login, and session cookies were correctly issued.
Additional Fix: Forgejo Git Service Timeout
During deployment, git pull timed out. Investigation revealed memory bloat in the Forgejo instance (exceeding 12 GB RAM / 5000+ threads), causing all HTTP requests to take over 3 seconds to respond. This was caused by high-frequency polling from Action Runners combined with aggressive crawler activity targeting large mirror repositories. Restarting the Forgejo container resolved the issue (memory usage dropped to ~140 MB), and git operations resumed normally.
Current Status
Login functionality at https://app.windfonts.com/login is working ✓
Automated deployment pipeline is operating normally ✓
Forgejo Git service has been restored ✓
Pending Follow-ups
Upgrade Forgejo from v11.0.3 → v11.0.10 (to address the root cause of memory leaks)