Create Project

Your servers come pre-configured with the runtime each framework needs — Node.js 24, PHP 8.4 (any version back to 7.0 can be pinned per project), plus any extra services (database, cache, etc.) you picked during provisioning. Ten frameworks are supported: Laravel, Next.js, Nuxt, Astro, Remix, React Router, WordPress, Symfony, Statamic, and plain PHP.

Starting the wizard #

In the Console, click Create Project in the top-right of the sidebar or the header.

There are two ways to make a project. This page is the first: you bring a repository and Depfloy builds and deploys it. The second is a one-click install — you pick an application such as WordPress from a catalog and Depfloy installs it, with no repository involved. The One-click install instead button at the top of this wizard switches to it.

Form fields #

The wizard walks you through these fields:

• Server — the server the project will live on. You’ll only see servers in the current organization that your role lets you create projects on.
• Source Control Provider — GitHub, Bitbucket, or any provider connected under Configuration → Source Control.
• Repository URL — the URL or org/repo identifier for your project.
• Branch — which branch to deploy. main for a typical setup; you might use staging or production on dedicated environments.
• Framework — Depfloy uses this to decide build and start commands. Pick the closest match; you can override anything later in Settings.
• Project Name — a friendly name shown in the sidebar.
• Preview URL — an editable address such as project-name.depfloy.app. Depfloy checks it before the form can be submitted and offers another hostname if it is already reserved.
• Project Domain — an optional production hostname. If you provide one, it stays primary and the preview URL remains available as a second address.
• Redirect Status — when a production domain is present, pick whether www.example.com redirects to example.com, the other way, or no redirect.
• Environment variables — paste the contents of your .env file here. You can also leave it empty and add them on the Environments tab after creating the project.
• Custom Install Command — overrides Depfloy’s default install command (for example to use pnpm install instead of npm install). Leave blank for the framework default.
• Custom Build Command — overrides the default build command.
• Enable Auto Deploy — when on, every push to the configured branch triggers a deployment.
• Enable SSL — when on, Depfloy issues a Let’s Encrypt certificate for the production domain after its DNS points at the server. Preview HTTPS is prepared separately and does not depend on this switch.

When everything’s filled in, click Create Project. Depfloy provisions the project on the server and triggers an initial deployment.

Your persistent preview URL #

Every new web project reserves a platform URL under depfloy.app. The address is public, stays with the project when you rename it or move it to another server, and receives its own HTTPS certificate. Setup progress and Retry setup are available on the Domains tab.

Business organizations can replace the preview base for new projects with a verified domain such as preview.example.com. See Custom preview domains.

Next.js: server-rendered or static export #

Both kinds of Next.js project work under the Next.js framework option — there’s nothing extra to configure.

• A server-rendered Next.js app runs as a Node.js application, exactly as before.
• A static export — a project built with output: 'export' in its Next.js config — is recognised automatically during deployment. Depfloy sees the exported build and publishes it as plain static files, without starting a Node.js application. This is what you want for a fully static landing or marketing site.

Sub-pages resolve the way you’d expect: a request for /pricing is served from the exported pricing.html.

The check runs on every deployment, so if you switch a project between static export and server rendering, a redeploy is all that’s needed.

Astro: static or server-rendered #

Pick Astro as the framework and leave it there — there is no output mode to choose. Depfloy reads the build to work out which kind of site it is:

• No adapter configured. Astro writes a static site to dist/, and nginx serves it directly. No application process runs and no port is used.
• @astrojs/node configured. The build writes dist/server/entry.mjs and Depfloy runs it as an application, setting PORT for you.

Only the adapter’s standalone mode is supported. In middleware mode Astro emits a request handler rather than a server that listens, so nothing ever answers on the port and the deployment fails its health check.

A static Astro site returns a real 404 for an address that doesn’t exist, showing your 404.html if you have one. It does not fall back to the homepage the way a single-page app does — Astro output is multi-page, and serving the homepage for every unknown URL would hide broken links from you and from search engines.

Custom deployment command #

For post-deploy work — cache warm-up, signal another service, ping a dashboard — add a custom deployment command on the Settings tab after the project is created.

You do not need to add commands like composer install, npm install, npm run build, or php artisan migrate — Depfloy runs these automatically as part of the build. The custom command runs after the symlink switch, inside the new release directory.

# Example: clear cache and bounce queue workers
php artisan cache:clear
php artisan queue:restart

For guidance on what to avoid in custom deployment commands (php artisan reverb:restart, long-running commands), see Developer Guide → Custom deployment commands.