Faça deploy de Nuxt na Nodion

Faça deploy de Nuxt passo a passo

1. Mantenha os scripts predefinidos e um lockfile Faça commit do seu lockfile; sem ele, o build falha. Os projetos Nuxt não trazem script start, e não precisa de um: a Nodion executa o seu script build e depois inicia .output/server/index.mjs, que escuta na porta PORT definida pela Nodion. Se adicionar um script start, a Nodion executa esse script em vez disso. package.json

   "scripts": {
     "build": "nuxt build",
     "dev": "nuxt dev"
   }

2. Crie a aplicação No dashboard, crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea, escolha o branch e a região EU Central e mantenha a estratégia de build em Buildpacks.
3. Configure com variáveis NUXT_ Declare as suas definições em runtimeConfig e defina-as como NUXT_API_SECRET ou NUXT_PUBLIC_API_BASE no separador Environment. O Nuxt lê-as quando o servidor arranca, por isso não precisam da opção Build. Só precisam dela os valores que o nuxt.config lê de process.env durante o build. nuxt.config.ts

   export default defineNuxtConfig({
     runtimeConfig: {
       apiSecret: "",
       public: {
         apiBase: "",
       },
     },
   });

4. 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 com um estado 2xx ou 3xx. Se / responder 401 ou 404, adicione uma rota de servidor como server/routes/health.ts e defina /health como caminho do health check nas definições da aplicação.

A ter em conta

• Site estático com nuxt generateA Nodion não deteta nuxt generate por si só e continua a iniciar o servidor. Para um site estático, use nuxt generate como script build e adicione um static.toml com output-dir = ".output/public". A Nodion serve então essa pasta com um servidor web estático e fallback para index.html, e o tamanho mais pequeno é suficiente.
• Preset do NitroA Nodion inicia .output/server/index.mjs, gerado pelo preset predefinido do Nitro, node-server. Se o nuxt.config ou NITRO_PRESET escolher um preset para outro fornecedor de alojamento, remova-o.

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

• 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.
• Cloud Native Buildpacks: o que são e como funcionam Os buildpacks transformam o seu código-fonte numa imagem de contentor sem Dockerfile. O que são e como funcionam.

Nuxt na Nodion: perguntas e respostas