> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.hodi.host/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# What can I deploy on Hodifly?

## Deployment types

* **Static site**: HTML/CSS/JS (including sites produced by a static site generator). Served directly as files. This is the fastest and simplest option.
* **PHP application**: Laravel, Symfony, and more broadly any Composer application with a front controller (Lumen, CodeIgniter, Yii, CakePHP, Slim…). Composer, migrations and cache warming run automatically on every deploy.
* **Node application**: a persistent Node server (Express, Fastify, NestJS) or a server-rendered framework: Next.js, Vinext, Nuxt, TanStack Start, Astro, SvelteKit, Remix.
* **Python application**: a WSGI application (Flask, Django, FastAPI).
* **Ruby application**: a Rack application (Ruby on Rails, Sinatra). Bundler, asset precompilation and migrations run automatically.

Hodifly picks the right type automatically.

||| ⚠️ Note: Node, Python and Ruby applications require SITE PRO web hosting. Static sites (including those built with Node or Python) and PHP applications, on the other hand, are compatible with all web hosting plans: PHP is served by the web server itself.
## Which frameworks are detected automatically?

Hodifly reads your `package.json`, your `composer.json`, your configuration files, and a few manifests to pre-fill the build command and output folder. Detected out of the box:

* **Static builds**: Next.js and Vinext (static export), Nuxt, Astro, SvelteKit, Gatsby, Angular, Eleventy, Docusaurus, Vue, Svelte, React (CRA and Vite), Hugo, Jekyll, as well as plain static HTML.
* **Node applications (server-rendered)**: Express, Fastify, Koa, Hapi, NestJS, plus Next.js, Vinext, Nuxt, TanStack Start, Astro, SvelteKit, Remix and React Router v7 as soon as they are configured for server rendering (see below).
* **PHP applications**: Laravel, Symfony, Lumen, CodeIgniter 4, Yii 2, CakePHP and Slim, recognised from `composer.json`, plus any other application that has a front controller.
* **Python applications**: Django, Flask, FastAPI (via `requirements.txt` / `pyproject.toml` / `manage.py` / `passenger_wsgi.py`).
* **Ruby applications**: Ruby on Rails, Sinatra and any Rack application, recognised from the `Gemfile` and `config.ru`.

### Static or server-rendered? Your repository decides

Several JavaScript frameworks can produce both. Hodifly does not guess: it reads your configuration.

* **Nuxt** is server-rendered by default and deploys as a Node application. Set `ssr: false` in `nuxt.config` to get a prerendered site (`nuxt generate`) instead.
* **Astro** is static unless the `@astrojs/node` adapter is installed, which makes it a Node application. Other adapters (Cloudflare, Vercel, Netlify) cannot run here and stay on the static path.
* **SvelteKit** follows its adapter: `@sveltejs/adapter-node` gives a Node application, otherwise `adapter-static` is assumed.
* **Vinext** (Next.js on Vite) reads your `next.config` like Next.js does: it deploys as a Node application, and `output: 'export'` publishes it static instead. It needs Node 22 or newer, so remove any older Node version pinned in `.nvmrc` or `engines.node`. A Vinext project set up for Cloudflare Workers (`@cloudflare/vite-plugin` in the Vite config) cannot run here: remove that plugin, or load it only when deploying to Cloudflare.
* **Remix** and **React Router v7** are Node applications. An `ssr: false` build is published static.
* **TanStack Start** is a Node application: it is built by Nitro, and its server functions need a server to answer them. `spa` and `prerender` do not change that. Ask Nitro for a static build (`nitro: { preset: 'static' }` in the Vite config) and the site is published static instead, with no application to keep running.

## PHP applications: what Hodifly does for you

For a Laravel or Symfony project, there is normally no build command to enter.

* **Document root**: the domain points at the **front-controller folder** inside the deployed release. That folder is `public/` for Laravel, Symfony, Lumen, CodeIgniter and Slim, `web/` for Yii, `webroot/` for CakePHP. `.env`, `vendor/`, `app/`, `config/` and `storage/` are therefore not reachable over HTTP. That folder can still be corrected in the project settings if your application is unusual.
* **Composer**: `install --no-dev --prefer-dist --optimize-autoloader` runs on every deploy. Commit your `composer.lock`.
* **`.env` file**: it is generated on every deploy from the project's environment variables. Do not commit a `.env`: a committed one is ignored, with a warning in the deploy log. `APP_KEY` (Laravel) and `APP_SECRET` (Symfony) are generated once and kept outside the releases, so sessions and encrypted columns survive deploys.
* **Migrations**: they run automatically before the new release goes live (`php artisan migrate --force`, or `doctrine:migrations:migrate` when the Doctrine migrations bundle is present). A failing migration fails the deploy, and the previous release keeps serving. Set the environment variable `HODIFLY_SKIP_MIGRATIONS=1` to opt out. Note that a rollback restores the code, but not the database schema.
* **Persistent data**: Laravel's `storage/` (uploads, logs, sessions) and Symfony's `var/log` and `var/sessions` live outside the releases and are symlinked into each one, so they survive deploys and rollbacks. Anything the application writes elsewhere inside its own directory is lost on the next deploy.
* **Front-end assets**: Vite, Laravel Mix and Webpack Encore all build automatically when your `package.json` has a `build` script.
* **Scheduled tasks**: if the application schedules anything (`routes/console.php` or `app/Console/Kernel.php`), Hodifly keeps a `* * * * * php artisan schedule:run` entry in the account's crontab, visible and editable in cPanel > Cron Jobs.
* **Queues and background workers**: supported. Laravel `queue:work`, Laravel Horizon and Symfony Messenger run as supervised processes, set up automatically on each deploy when your application needs one, and restarted so they always run your new code. You can also manage them by hand in **cPanel > Workers**. More info: [How do I run background workers (queues, Horizon, Messenger)?](https://help.hodi.host/en/article/how-do-i-run-background-workers-queues-horizon-messenger-1je5zfw/)
* **Not available**: WebSockets servers (Reverb, Soketi) and Laravel Octane. For real-time features, use polling, or a virtual or dedicated server where you control the whole stack.

## Advanced build settings

### Package path (monorepo support)

If your application is in a subfolder of the repository (a monorepo), specify that folder in the **package path** (*Package path*). Dependency installation, the build, and the publish step then run there. You can deploy several applications from the same repository by creating one project per subfolder: each one only rebuilds when the files in its own folder change.

### Build command and build folder

* **Build command**: what Hodifly runs (for example `npm run build`). Leave this field empty for a repository that is already pre-built, or for a Laravel or Symfony application whose Composer and asset steps are handled automatically.
* **Build folder**: the directory produced by your build that Hodifly publishes (for example `dist`, `build`, `out`, `public`, `_site`).

### Runtime

Choose the version of **PHP**, **Node**, **Python** or **Ruby** used to build and run your project. For a PHP project the version is pre-filled from your `composer.json` constraint (`">=8.2"` gives 8.2) and you can raise it if a dependency requires it; Hodifly also aligns the domain's MultiPHP version, so do not change it afterwards in cPanel. Select **None** for a static site that is delivered already built, with no build step (this skips the `npm install` step).

### Environment variables

Add your key/value variables under **Environment variables**. They are passed to your **build command** (for example `API_URL`, `NODE_ENV`), to the running application for Node and Python applications, and are used to generate the `.env` for PHP applications. They are:

* **Stored on your own server**, never sent to Hodifly's control plane.
* **Encrypted at rest.**
* Not publicly displayed.