TypeScript · Node.js 22
Hospedagem TypeScript 24/7
Dois caminhos, os dois suportados: compilar com tsc e apontar o MAIN para dist/index.js, ou deixar o tsx executar o .ts em produção. O que a plataforma pede é que a decisão esteja no package.json e no vertracloud.config.
Quem desenhou o TypeScript
Anders Hejlsberg, já autor do Turbo Pascal e do C#, publicou o TypeScript na Microsoft em 2012: JavaScript com um sistema de tipos que some na compilação. A 0.8 saiu naquele ano; a 1.0, em 2014. A tese era gradual — você anota o que cabe, o resto continua JS — e o emit é a mesma linguagem que o navegador já rodava. Não há máquina virtual nova: só um passo a mais no editor e no compilador.
Anders Hejlsberg
DBegley · CC BY 2.0
JavaScript com tipos
É isso o produto: a mesma linguagem da web, com um sistema de tipos no editor. Não é um runtime novo nem uma VM — é o JavaScript que você já tinha, anotado.
Os tipos não embarcam
Na compilação eles desaparecem. O que o motor executa é JavaScript puro, o mesmo que o navegador já rodava em 1995.
Para código que cresce
Hejlsberg vinha de bases grandes em C# e Delphi. O TypeScript existe para times e arquivos que o JS solto deixa escapar — a migração é gradual, arquivo a arquivo.
O que a plataforma faz por um projeto TypeScript
O build acontece no servidor, com a saída inteira no terminal — erro de tipo não vira crash silencioso em produção.
Compilado ou executado direto
Com tsc, MAIN aponta para dist/index.js e o START roda o script que compila antes de subir. Com tsx, o MAIN é o próprio .ts. A plataforma não impõe nenhum dos dois — ela executa o que o seu package.json manda.
tsconfig.json vale no build
O arquivo de configuração vai no zip e é o mesmo que o compilador lê no servidor. Alvo, module, paths e strict se comportam igual à sua máquina, e um erro de compilação aparece no log do build dentro do teto de 5 minutos.
dist não é limpo do pacote
A plataforma remove node_modules e .next do zip, mas nunca a pasta de saída. Quem faz bundle antes do deploy pode enviar dist pronto e apontar o MAIN para dentro dela, sem compilar de novo no servidor.
Auto-restart com freio
O processo que cai é reiniciado sozinho, em qualquer plano: o erro em runtime que o tipo não pegou não derruba o serviço. Se ele quebrar 5 vezes em 10 minutos, o auto-restart é desativado por 24 horas — e a saída com exit code 0 segue sendo tratada como fim normal, sem reinício.
O que as pessoas rodam em TypeScript aqui
Tipagem serve tanto para a API que outra equipe consome quanto para o bot que só você mantém.
APIs Nest, Fastify e Hono
Publique a aplicação para receber um subdomínio em vertraweb.app com TLS. Se você compila para dist, é o servidor compilado que precisa escutar em 0.0.0.0 na porta declarada em PORT — bind em localhost devolve timeout.
Bots de Discord tipados
discord.js com tipos de comando e evento roda como processo de background, sem porta HTTP. O token vai nas variáveis de ambiente do painel, nunca num .env dentro do zip.
Workers e jobs com Prisma ou Drizzle
Consumidor de fila, rotina agendada, ETL: o schema tipado sobe junto com o código. Rode a migração como parte do seu script de start, não no build.
ORM tipado com banco gerenciado
Prisma e Drizzle apontam para um PostgreSQL 17 ou um MySQL 8.0 criado no mesmo painel, pelo host interno. TLS é obrigatório: o certificado e a senha são gerados pela plataforma e ficam disponíveis para download.
Versões de Node.js para TypeScript
TypeScript roda sobre o Node.js: a recomendada é a 22, e 20 e 18 seguem disponíveis. Para fixar uma delas, declare VERSION no vertracloud.config.
| Versão | vertracloud.config | Status |
|---|---|---|
| Node.js 22 | VERSION=22 | RecomendadaMais recente |
| Node.js 20 | VERSION=20 | |
| Node.js 18 | VERSION=18 |
A configuração inteira
O vertracloud.config é um arquivo INI opcional na raiz do projeto. Aqui o MAIN aponta a saída compilada e o START chama o script do package.json; BUILD roda a compilação a cada deploy, antes de o app subir; VERSION escolhe o Node.js e MEMORY define o teto de RAM.
NAME=minha-api
MAIN=dist/index.js
START=npm start
VERSION=22
MEMORY=512Um plano para cada fase do projeto
A memória e o armazenamento mudam por plano; a linguagem, não. Compare o que cada plano libera e escolha o que cabe no projeto agora.
Comparar planosTambém roda aqui
Mesma plataforma, mesmo deploy, outra stack.
Perguntas frequentes sobre hospedagem TypeScript
tsc ou tsx, dist ou servidor: as dúvidas que separam os dois caminhos.
O log diz tsx: command not found ou ts-node: command not found.
Quem executa o .ts em produção é dependência de execução, não de desenvolvimento. Adicione o tsx a dependencies do package.json — em devDependencies ele não é instalado no build e o start morre na primeira linha.
O build falha com TSError: Unable to compile.
Verifique se o tsconfig.json foi para o zip: sem ele o compilador usa o padrão e reclama de coisas que passam na sua máquina. Corrija os erros de tipo antes do deploy — o build não sobe código que não compila.
Devo enviar a pasta dist ou compilar no servidor?
Os dois funcionam. Enviando dist pronto, aponte MAIN=dist/index.js e não exclua a pasta do zip. Compilando no servidor, deixe o START chamar um script que roda tsc antes de iniciar o processo.
Recebi Cannot find module de um pacote que existe no meu projeto.
O pacote está em devDependencies, ou o caminho compilado não bate com o alias do tsconfig. Mova a dependência de execução para dependencies; se você usa paths, confirme que a saída compilada resolve o caminho real.
O que a plataforma remove do zip antes do build?
node_modules, .npm, package-lock.json e .next saem do pacote. As pastas de saída, dist e build, não: elas ficam de propósito, porque em muitos projetos o MAIN aponta para dentro delas.
Suba seu projeto TypeScript hoje
Crie a conta, envie um zip ou conecte o repositório do GitHub e acompanhe a compilação pelo terminal do painel.
Criar conta