Deploy 13 runtimes, one contract
Ship long-running applications from the CLI or a connected GitHub repository, with logs, domains and configuration in one place. Node, Python, Go, ASP.NET Core, Rust, Java, Bun, Deno, PHP and Ruby are built for you; anything else arrives as a Dockerfile.
- 13 runtimes including Docker
- Rootless containers
- Automatic rollback on a failed probe
From repository to running app
Deploy with the CLI or connect a GitHub repository. The CLI detects the runtime from the files in your project, and --runtime overrides it when you would rather decide yourself.
Compiled before it starts
Go, .NET, Rust, Java, Bun, Deno, PHP and Ruby are built in a throwaway container with capabilities dropped and a hard memory limit, then started read-only. Dependency caches survive deployments, so the second build is markedly faster than the first.
Isolated by construction
Each application runs in a rootless Podman container with a read-only root filesystem, all capabilities dropped, no new privileges and a hard memory limit.
Deployments that can go back
The old container is stopped and renamed, the new one started and probed over HTTP. Only a passing probe retires the previous version; a failure returns to it.
A hard memory limit is a limit
Exceeding the configured memory kills the container through the kernel. It is not a soft warning threshold, and the restart policy retries a bounded number of times.
Configuration next to the app
Environment variables, domains and logs belong to the application resource, so there is no second console to keep in sync.
Logs where the app is
Live log streams come over a realtime channel rather than a polling loop, so tailing an application feels like tailing a local process.
Bring your own build, or let the server build it
Next.js needs output: 'standalone' and NestJS uses dist/main.js, because Node applications upload their finished build. Compiled runtimes upload their sources instead and are built on the server. In every case the application must listen on 0.0.0.0 and bind the PORT it is given. Beyond that, Veltic does not ask you to restructure your project.
The language that is missing arrives as a Dockerfile
Docker is a first-class runtime, not a workaround: the Dockerfile in your deployment is built and run as the container image, with the same dropped capabilities, hard memory limit and loopback-only port as everything else. Its filesystem stays writable, because a foreign image usually needs it, and its process limit grows with its memory limit so that a headless browser can start.
A redeploy is not a rolling reload
There is a brief interruption while containers are swapped. If your workload cannot tolerate that, put a queue in front of it rather than assuming zero downtime you were never promised.
veltic apps deploy PROJECT_ID storefront ./ --runtime nextjs
veltic apps deploy PROJECT_ID orders-api ./ --runtime go
veltic apps logs PROJECT_ID storefront --followBuild the whole backend in one project
One plan, one dashboard, one command line interface. PostgreSQL, applications, functions, storage and realtime.