First, an introduction to the condev-monitor project. This project recreates a Sentry-like frontend monitoring system. It mainly consists of the following parts: an SDK for monitoring errors and performance, an examples/vanilla frontend project used to test SDK integration, a dsn-server backend service that receives error reports from the SDK, and the dashboard frontend frontend/monitor with its backend backend/monitor.
At the beginning, I planned to deploy with docker-compose on Coolify. After many attempts, the network kept being pruned by Coolify during deployment, and many issues appeared. It may have been a conflict between Caddy in docker-compose and Coolify's own Caddy service. After repeated failures, I bought a new server and switched to a direct docker-compose deployment.
The project is deployed with docker-compose and uses many images. In development, it uses two database images, ClickHouse and Postgres, while other parts are developed locally with pnpm start:dev and pnpm dev. In development, .env is maintained by each subproject. For production, the two mainstream deployment options for Next.js are Nixpacks and Docker. For self-hosting needs, Next.js can use the OpenNext adapter to deploy on Cloudflare, and the NestJS backend can be deployed on an internal enterprise host through a tunnel. Or both frontend and backend can be deployed on an internal host with docker-compose. For the two backends, NestJS cannot be deployed without node_modules, so backend deployment either needs PM2 on the server or needs node_modules bundled into Docker images. I tried running PM2 on the server, and also tried PM2 for the OpenNext project, but errors occurred. So I later chose full docker-compose deployment on the server. By this point, I had already run into pitfalls with both Coolify and the PM2 + docker-compose hybrid approach.
I used an Alibaba Cloud 2C2G machine with AliLinux for Docker image deployment, but OOM crashes kept happening. Swap was configured, but still not enough. So I later planned to run the backend with PM2 and containerize only ClickHouse and Postgres, but after trying it, the deployment steps were too cumbersome, so I dropped it and switched to full docker-compose deployment. In the dashboard NestJS backend, argon2 failed to compile on Alibaba Cloud with the default Python 3.6. I tried switching to Python 3.7 and recompiling, but it still failed. Since this kept happening, I directly replaced that encryption dependency with bcryptjs.
Another issue was during docker-compose deployment on Alibaba Cloud: when using the older nest-modules/mailer in the dashboard NestJS backend, it reported missing CSS-in-JS dependencies. I found a solution in GitHub issues, but it was not very standard and the process was tedious. Future maintenance would likely be even harder, so I switched to nodemailer.
OOM issues kept happening on Alibaba Cloud, so I moved to an external Netcup 4C6G machine. This avoided complicated ICP filing and Docker image setup, and also avoided the issue of OpenAI services being unavailable in China during later development of other AI projects (the Cloudflare Worker workaround is no longer effective). Full docker-compose image deployment worked normally, but testing showed email sending and receiving did not work. After testing with machine scripts, I found the server did not support SMTP email sending. So based on the previous nodemailer setup that used 163 SMTP, I now prioritize Resend's HTTP email service, and fall back to SMTP when HTTP sending fails. This ensures email service keeps working when severe errors occur.
So far, these are the errors and pitfalls encountered in dependency replacement and deployment for this project.