Supported frameworks

Everything in this table has been deployed end to end in our tests: detected, built, started, health-checked and served on its own address.

When you upload a ZIP or analyze a repository, ProHostiva reads the files at the top level of your project (it never runs anything at this point) and shows you what it found: the framework, the runtime version, and the commands it will use to install, build and start your app. You can change the commands and the output folder before deploying if you need to.

Some project folders match more than one kind: a Laravel app also has a package.json, for example. In that case the first match in this order wins:

• A Dockerfile at the top level (always wins)
• Laravel, then other PHP
• Ruby on Rails
• Django
• Node.js frameworks (most specific first: Next.js, Nuxt, SvelteKit, Angular, Vite apps, then any Node server)
• Python (FastAPI, Flask)
• A static site (an index.html at the top level)

Static HTML

An index.html at the top level. Your files are served as they are, with no build step. Hidden files such as .env are never served.

React, Vue, Svelte (Vite) and Angular

Recognised from package.json. We install your dependencies with the package manager your project uses (npm, pnpm, yarn or bun, chosen from your lockfile), run your build script, and serve the result as fast static files. Links to pages inside your app work on refresh too.

These run as a server. We build your project and start it; your app must listen on the port given in the PORT environment variable, which frameworks do by default.

Dependencies are installed from requirements.txt, pyproject.toml (standard or Poetry) or a Pipfile. FastAPI runs with uvicorn; Django and Flask with gunicorn.

• FastAPI and Flask: we find your app object in the usual files (main.py, app.py, app/main.py and similar). If we can't, set the start command yourself.
• Django: needs manage.py and a wsgi.py. Static files are collected when STATIC_ROOT is set. Add your ProHostiva address and your domains to ALLOWED_HOSTS.
• Database migrations are never run automatically; run them when you're ready.

PHP 8.4 behind nginx. Composer packages are installed if there's a composer.json. Your .env, vendor folder and Composer files are never served.

• Plain PHP needs an index.php at the top level.
• Laravel is served from public/ and needs the APP_KEY environment variable. Migrations are never run automatically.

Built on the exact Ruby release your Gemfile or .ruby-version names, with bundle install; assets are precompiled during the build; served by Puma. Set SECRET_KEY_BASE or RAILS_MASTER_KEY as an environment variable. Migrations are never run automatically.

A Dockerfile at the top level is always used, whatever else is in the project. We check it against our safety rules first (no privileged mode, host networking or access to the platform), build it, and run it as one container. Expose one port; without an EXPOSE line we expect your app on port 8080. The PORT environment variable is set to that port.

• Docker Compose and other multi-container setups. We run one container per website; a docker-compose.yml next to a Dockerfile is ignored.
• Projects in a subfolder (monorepos). The app must be at the top level of the ZIP or repository.
• Recognised, but not yet in our end-to-end tests: TanStack Start, Create React App and Vue CLI, and Angular with server-side rendering. They may deploy fine; if yours doesn't, email us.

Using something else? Try the free readiness check: it tells you whether your project can be deployed and what would need to change.

We use the version your project asks for: engines.node or .nvmrc for Node, .python-version, runtime.txt or requires-python for Python, .ruby-version or the Gemfile for Ruby. If it asks for one we don't have, we use the closest one and say so on the Project detected card.