Faça deploy de SvelteKit na Nodion

Faça deploy de SvelteKit passo a passo

1. Mude de adapter-auto para adapter-node Execute npm i -D @sveltejs/adapter-node, remova @sveltejs/adapter-auto e use o novo adapter na sua configuração. A Nodion lê o adapter do package.json, e a configuração decide o que o build gera, por isso altere ambos. No SvelteKit 3, a configuração fica nas opções de sveltekit() em vite.config.js; no SvelteKit 2, é kit.adapter em svelte.config.js. vite.config.js (SvelteKit 3)

   import adapter from "@sveltejs/adapter-node";
   import { sveltekit } from "@sveltejs/kit/vite";
   import { defineConfig } from "vite";
   
   export default defineConfig({
     plugins: [
       sveltekit({
         adapter: adapter(),
         paths: { origin: "https://shop.example.com" },
       }),
     ],
   });

2. Faça commit do lockfile, dispense o script start Faça commit do seu lockfile; sem ele, o build falha. A Nodion executa o seu script build e inicia node build, e o adapter-node escuta na porta PORT definida pela Nodion. Um script start, se o adicionar, substitui esse comando.
3. Defina a origem pública A Nodion termina o HTTPS à frente da sua aplicação, por isso o SvelteKit não consegue saber, a partir do pedido, que URL os seus visitantes usam, e sem ele os envios de formulários são rejeitados como cross-site. No SvelteKit 3, defina paths.origin com o seu URL público, como na configuração acima; substitui a variável ORIGIN do adapter-node. No SvelteKit 2, defina antes ORIGIN no separador Environment, por exemplo https://shop.example.com.
4. Variáveis de build e de runtime Os valores de $env/static/private e $env/static/public são inseridos no código durante o build, por isso precisam da opção Build no separador Environment. $env/dynamic/private e $env/dynamic/public são lidos enquanto o servidor está em execução e funcionam com variáveis normais.
5. Crie a aplicação e faça push No dashboard, crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea na região EU Central. Cada push faz o build de uma nova release, e o tráfego passa para ela assim que / responde com um estado 2xx ou 3xx. Se / responder 401 ou 404, adicione uma rota como src/routes/health/+server.js que devolva 200 e defina /health como caminho do health check.

A ter em conta

• Sites estáticos com adapter-staticCom @sveltejs/adapter-static, a Nodion serve build/ com um servidor web estático e fallback para index.html. Faça o prerender das páginas com export const prerender = true no +layout.js da raiz. Para uma single-page app, desative aí o SSR e defina fallback: 'index.html' nas opções do adapter, porque a Nodion precisa de um index.html em build/. Não há nenhum servidor Node.js em execução, por isso o tamanho mais pequeno é suficiente.
• Um só adapter no package.jsonA Nodion procura primeiro adapter-static e depois adapter-node. Se ambos estiverem instalados, a aplicação é construída como site estático, por isso remova o adapter que não usa.

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.
• Dockerfile vs buildpacks: qual deve escolher? Ambos transformam o seu código numa imagem de contentor. A diferença está em quem escreve os passos do build, e isso determina o controlo, a manutenção e as atualizações de segurança.

SvelteKit na Nodion: perguntas e respostas