TypeScript · Node.js 22
TypeScript hosting, 24/7
Two paths, both supported: compile with tsc and point MAIN at dist/index.js, or let tsx run the .ts in production. What the platform asks is that the decision lives in package.json and vertracloud.config.
Who designed TypeScript
Anders Hejlsberg, already the author of Turbo Pascal and C#, published TypeScript at Microsoft in 2012: JavaScript with a type system that erases at compile time. 0.8 shipped that year; 1.0 in 2014. The thesis was gradual — you annotate what you can, the rest stays JS — and the emit is the same language the browser already ran. There is no new virtual machine: only an extra step in the editor and the compiler.
Anders Hejlsberg
DBegley · CC BY 2.0
JavaScript with types
That is the product: the same language of the web, with a type system in the editor. It is not a new runtime or a VM — it is the JavaScript you already had, annotated.
The types do not ship
They vanish at compile time. What the engine runs is plain JavaScript, the same thing the browser already ran in 1995.
For code that grows
Hejlsberg came from large C# and Delphi codebases. TypeScript exists for teams and files that loose JS lets slip — migration is gradual, file by file.
What the platform does for a TypeScript project
The build happens on the server with its whole output in the terminal — a type error never becomes a silent production crash.
Compiled or run directly
With tsc, MAIN points at dist/index.js and START runs the script that compiles first. With tsx, MAIN is the .ts file itself. The platform imposes neither — it runs what your package.json says.
tsconfig.json applies at build time
The config file ships in the zip and is the same one the compiler reads on the server. Target, module, paths and strict behave as they do on your machine, and a compile error appears in the build log within the 5-minute ceiling.
dist is not stripped from the package
The platform removes node_modules and .next from the zip, never your output folder. If you bundle before deploying, ship a ready dist and point MAIN inside it, with no second compile on the server.
Auto-restart with a brake
A process that crashes is restarted on its own, on every plan: the runtime error the types did not catch does not take the service down. If it breaks 5 times in 10 minutes, auto-restart is disabled for 24 hours — and exiting with code 0 is still read as a normal end, with no restart.
What people run in TypeScript here
Types earn their keep both on the API another team consumes and on the bot only you maintain.
Nest, Fastify and Hono APIs
Publish the application to get a vertraweb.app subdomain with TLS. If you compile to dist, it is the compiled server that has to listen on 0.0.0.0 at the port declared in PORT — binding to localhost returns a timeout.
Typed Discord bots
discord.js with typed commands and events runs as a background process, with no HTTP port. The token goes in the dashboard environment variables, never in a .env inside the zip.
Workers and jobs with Prisma or Drizzle
Queue consumer, scheduled routine, ETL: the typed schema ships with the code. Run migrations as part of your start script, not during the build.
A typed ORM on a managed database
Prisma and Drizzle point at a PostgreSQL 17 or MySQL 8.0 created in the same dashboard, over the internal host. TLS is mandatory: certificate and password are generated by the platform and available to download.
Node.js versions for TypeScript
TypeScript runs on top of Node.js: 22 is the recommended one, and 20 and 18 are still available. To pin one, declare VERSION in vertracloud.config.
| Version | vertracloud.config | Status |
|---|---|---|
| Node.js 22 | VERSION=22 | RecommendedLatest |
| Node.js 20 | VERSION=20 | |
| Node.js 18 | VERSION=18 |
The whole configuration
vertracloud.config is an optional INI file at the project root. Here MAIN points at the compiled output and START calls the package.json script; BUILD runs the compile step on every deploy, before the app starts; VERSION picks the Node.js and MEMORY sets the RAM ceiling.
NAME=minha-api
MAIN=dist/index.js
START=npm start
VERSION=22
MEMORY=512A plan for every stage of the project
Memory and storage change with the plan; the language does not. Compare what each plan unlocks and pick the one that fits the project today.
Compare plansAlso runs here
Same platform, same deploy, a different stack.
Frequently asked questions about TypeScript hosting
tsc or tsx, dist or server: the questions that separate the two paths.
The log says tsx: command not found, or ts-node: command not found.
Whatever runs your .ts in production is a runtime dependency, not a development one. Add tsx to package.json dependencies — in devDependencies it is not installed at build time and the start dies on the first line.
The build fails with TSError: Unable to compile.
Check that tsconfig.json made it into the zip: without it the compiler falls back to defaults and complains about code that passes on your machine. Fix the type errors before deploying — the build will not ship code that does not compile.
Should I ship the dist folder or compile on the server?
Both work. Shipping a ready dist, set MAIN=dist/index.js and keep the folder in the zip. Compiling on the server, let START call a script that runs tsc before starting the process.
I get Cannot find module for a package that exists in my project.
Either the package sits in devDependencies, or the compiled path does not match your tsconfig alias. Move the runtime dependency to dependencies; if you use paths, confirm the compiled output resolves to the real path.
What does the platform strip from the zip before the build?
node_modules, .npm, package-lock.json and .next are dropped from the package. The output folders, dist and build, are not: they stay on purpose, because in many projects MAIN points inside them.
Deploy your TypeScript project today
Create an account, upload a zip or connect your GitHub repository, and follow the compilation in the dashboard terminal.
Create account