Supported languages & frameworks
The Deployer reads your code before it deploys anything, so it works best when it recognizes the language and framework you built with. The good news: it understands the most popular ones, and it's smart about figuring out how your app is meant to run.
What it can deploy
The Deployer looks inside your repository, identifies what kind of app it is, and sets up the right build and run steps automatically. These are the languages and frameworks it understands:
| Language | Frameworks & notes |
|---|---|
| Node.js / JavaScript / TypeScript | Plain Node apps plus front-end build tools like Vite, Create React App, and Next.js. For front-ends, it even bakes your settings into the build so the finished site talks to the right address. |
| Python | Django, Flask, and FastAPI (and standard Python web apps). |
| Go | Go web services and APIs. |
| Java | Spring applications. |
| Ruby | Ruby on Rails. |
| PHP | PHP web apps. |
| Static sites | Plain HTML/CSS/JS and sites produced by a build step (nothing to keep running — just files to serve). |
If your project is a web app, an API, a static site, or a background worker written in one of these, you're in good shape.
What the scanner figures out for you
You don't have to hand-configure any of this. When The Deployer scans your repo, it works out:
- How to build it — the build and start commands, read from your project files.
- Which port it listens on, so visitors reach the right place.
- Its routes and a health-check endpoint, so we can confirm the app is actually up before calling a deploy "done."
- The language version it expects (for example, which Node or Python version).
- Lock files, so it installs the exact dependency versions your project pins.
- Extra services it needs, like a database or a cache, so those can be set up alongside it.
This is why most apps deploy without you filling in a long form — the app learns what it needs by reading your code.
When something's missing, it can fill the gap
Two things often trip people up when going live: not having a Dockerfile (the recipe for packaging your app) and not having a health-check endpoint (a simple "am I alive?" URL). The Deployer can generate or repair both for you when they're absent, and it commits those small changes to a branch so you can see exactly what it added.
If your stack isn't listed
The list above covers the vast majority of web projects, but not literally everything. Very unusual setups, or apps that need special hardware (like GPUs for machine learning), may not be a fit — see what the app can't (yet) do for the honest boundaries. If you're unsure whether your project will work, connect your repository and let The Deployer scan it: it reads your code and shows you the plan it would follow, so you can see how it understands your app before you launch.