프레임워크 기능은 Node.js 서버에서도 돌아
서버 컴포넌트, RSC 스트리밍, ISR, 서버 액션, 이미지와 글꼴 최적화는 Vercel 전용 문법이 아니야. 빌드 뒤 next start로 표준 Node.js 서버에서 실행할 수 있어. 달라지는 건 SSL, 프로세스 생존, CDN, 캐시 공유를 직접 운영한다는 점이야.
빌드와 실행을 분리해
npm run build로 production 산출물을 만든 뒤 npm run start로 실행해. 기본 포트는 3000이고 -p로 바꿀 수 있어. 기본 서버는 단일 프로세스이므로 PM2, systemd, launchd, Docker orchestrator 같은 관리자가 재시작과 확장을 맡아야 해.
앞단 proxy가 네트워크 책임을 가져
nginx나 Caddy를 next start 앞에 두면 TLS 종료, 요청 로그, gzip·brotli 압축을 처리할 수 있어. Caddy는 인증서 자동 관리가 필요할 때 단순한 선택이야.
이미지 최적화에는 sharp가 필요해
자체 호스팅의 이미지 optimizer는 내부적으로 sharp를 사용해. production 의존성으로 명시해 빠진 채 배포되어 최적화되지 않은 원본으로 돌아가는 일을 막아.
자체 호스팅 전에 Vercel이 맡던 항목을 TLS, process, cache, image, log, backup, deploy로 나누고 각각 구현과 담당자를 배정해. 프로세스를 강제 종료해 재시작되는지, 여러 인스턴스에서 ISR 결과가 일치하는지, 인증서 갱신이 자동인지 실제 장애로 시험해. next start가 뜬다는 건 단일 호스트의 기능 확인일 뿐 운영 준비가 아니야. health check가 프로세스만 보고 DB와 정적 자산 실패를 놓칠 수 있어. 반대로 작은 내부 도구라면 거대한 orchestrator가 더 큰 장애 원인이 될 수 있으니 요구 규모에 맞춰 책임을 선택해. next start 앞에 TLS proxy와 process manager를 두고 프로세스 kill, 인증서 갱신, 로그 회전, 여러 인스턴스 ISR을 시험해. 이미지 요청이 sharp로 최적화되는지와 health check가 DB 장애를 잡는지도 보고, 복구 명령을 다른 사람이 따라 할 수 있게 남겨.