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, Nuxt, 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.

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 (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, Nuxt, 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.

\1

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.
• Remix and React Router v7 are Node applications. An ssr: false build is published static.

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.
• Not available: WebSockets and long-running processes (Octane, Horizon, Reverb, Messenger workers). For queues, add a cron job * * * * * php artisan queue:work --stop-when-empty --max-time=55, or use QUEUE_CONNECTION=sync for low-volume apps.

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.

Updated on: 15/08/2026