Articles on: 🌍 Web Hosting
This article is also available in:

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 or Symfony. Composer, migrations and cache warming run automatically on every deploy.
  • Node application: a persistent Node server (Express, Fastify, NestJS, Next.js in SSR, etc.).
  • Python application: a WSGI application (Flask, Django, FastAPI).


Hodifly picks the right type automatically.


⚠️ Note: Node and Python 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 (static export), Nuxt, Gatsby, Astro, SvelteKit, Angular, Eleventy, Docusaurus, Vue, Svelte, React (CRA and Vite), Hugo, Jekyll, as well as plain static HTML.
  • PHP applications: Laravel and Symfony, recognised by a composer.json alongside artisan, bin/console or public/index.php.
  • Node applications: Express, Fastify, Koa, Hapi, NestJS, and Next.js in server mode (SSR).
  • Python applications: Django, Flask, FastAPI (via requirements.txt / pyproject.toml / manage.py / passenger_wsgi.py).


Detection remains a best-effort estimate: you can always change the build command, the build folder, the runtime, and the type before deploying.


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 public/ folder inside the deployed release, so .env, vendor/, app/, config/ and storage/ are not reachable over HTTP.
  • 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 or Python 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: 05/08/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!