Faça deploy de Next.js na Nodion

Faça deploy de Next.js passo a passo

1. Mantenha um lockfile e os scripts habituais Faça commit de package-lock.json, yarn.lock, pnpm-lock.yaml ou bun.lock; sem lockfile, o build falha. O next start escuta na porta PORT definida pela Nodion, por isso os scripts predefinidos funcionam tal como estão. package.json

   "scripts": {
     "build": "next build",
     "start": "next start"
   }

2. Crie a aplicação No dashboard, crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea e escolha o branch e a região EU Central. Mantenha a estratégia de build em Buildpacks; se o repositório tiver um Dockerfile, o formulário escolhe Dockerfile em vez disso.
3. Defina as variáveis de ambiente Tudo o que o next build lê, como NEXT_PUBLIC_*, precisa da opção Build no separador Environment; todas as outras variáveis só existem em runtime. Marque as chaves de API como secretas.
4. Associe o PostgreSQL e execute as migrações Crie uma base de dados na mesma região e associe-a no separador Environment; no próximo deploy, a aplicação recebe DATABASE_URL. Uma linha release: num Procfile é executada uma vez por build, antes de a nova versão arrancar. Mantenha a ferramenta de migrações em dependencies: as dependências de desenvolvimento são removidas depois do build. Procfile

   release: npm run migrate

5. Faça push para fazer deploy Cada push para o branch faz o build de uma nova release. O tráfego passa para ela assim que responde em / com um estado 2xx ou 3xx; se o passo de release falhar, a versão em execução continua online.

A ter em conta

• Exportação estáticaCom output: 'export' no next.config, a Nodion serve out/ com um servidor web estático e fallback para index.html. Não há nenhum servidor Node em execução, por isso o tamanho mais pequeno é suficiente.
• Caminho do health checkSe / responder 401 ou 404, defina nas definições da aplicação um caminho de health check que devolva 200, por exemplo um route handler em /api/health.
• MonoreposDefina o Base directory para a pasta da aplicação Next.js. O build só vê essa pasta, por isso o lockfile tem de estar lá.

O que a Nodion gere por si

• Deploys sem downtime Faça push para o seu branch e a Nodion cria uma nova release. O tráfego só muda quando as novas instâncias passam no health check; se uma release falhar, a que está em execução mantém-se. Em vez disso, as aplicações com um volume local são reiniciadas, porque o disco pertence a uma única instância.
• Bases de dados junto à aplicação PostgreSQL, pgvector, MySQL, Valkey e ClickHouse geridos, na mesma região. As bases de dados associadas chegam como DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Pré-visualizações por pull request Ative as pré-visualizações e cada pull request do seu repositório passa a ter uma aplicação própria, com URL próprio e bases de dados novas e vazias, criada automática ou manualmente. Os forks e os pull requests de bots são ignorados.
• Workers, cron jobs e escalabilidade Execute workers como processos adicionais da mesma aplicação, agende tarefas no separador Cron e escale cada processo até 16 instâncias.
• Etapa de release Com buildpacks, uma linha release: do Procfile é executada a cada novo build. As aplicações com Dockerfile, bem como os redeploys ou rollbacks para uma imagem anterior, usam um comando de release definido na própria aplicação, que também tem prioridade sobre a linha do Procfile. Nos sites estáticos, a etapa de release é executada numa imagem que contém apenas os ficheiros gerados pelo build.
• Logs e métricas Logs de build, release e runtime, além de métricas de CPU, memória, disco e rede de cada instância, no dashboard.
• Domínios e HTTPS Um hostname atribuído por omissão com HTTPS desde o primeiro deploy; os seus próprios domínios recebem certificados automaticamente.

Para saber mais

• Alternativas ao Vercel na Europa: 5 opções para Next.js Funções no edge ou um servidor Node.js sempre ativo junto à sua base de dados: cinco alternativas ao Vercel para Next.js, comparadas por modelo de execução e localização.
• Ambientes de pré-visualização: uma aplicação por pull request Uma cópia em execução da sua aplicação para cada pull request: para que servem os ambientes de pré-visualização, onde se complicam e como a Nodion os gere.

Next.js na Nodion: perguntas e respostas