Sites

A site is an application running on one of your servers — a domain, a project type, a Git repository, environment variables, and a deploy script, all managed from a single page.

Overview

Every site in Deploynix lives inside an App Server or Web Server. Each site runs under its own Unix user and its own PHP-FPM pool, so sites on the same server can't read each other's files or share a process crash. When you create a site you pick a project type — Laravel, WordPress, Statamic, a JavaScript framework, or a static bundle — and Deploynix sets up Nginx, the correct web directory, a dedicated system user, a starter deploy script, and a free subdomain under *.deploynix.cloud with a wildcard TLS certificate so you can hit the site over HTTPS before you've configured DNS.

Project Types

Deploynix groups project types into three categories. The category decides which software runs your code (PHP-FPM, a built static bundle, or a long-running Node process).

Laravel and PHP frameworks default their web directory to /public, WordPress to the site root, SPAs to their build directory, and SSR frameworks to an empty directory since Nginx proxies to Node rather than serving files.

Creating a Site

1. Open the server where you want the site and click Add Site on the Sites tab.
2. Pick a project type. The form adapts to show only the fields that apply.
3. Set the web directory. Defaults are correct for most projects — override only if your app has an unusual layout.
4. Choose a PHP version if the project is PHP-based: 8.4, 8.3, 8.2, 8.1, or 8.0. Each site can run a different PHP version on the same server.
5. Pick a database option: none, SQLite, a database on this server, or a remote database server. For WordPress, Deploynix will create the database and user automatically.
6. Pick a cache option: none, Valkey on this server, or a remote cache server.
7. Connect a Git repository — pick one of your connected GitHub / GitLab / Bitbucket accounts or paste a public HTTPS URL, then choose a branch.
8. Decide whether zero-downtime deployments should be on (recommended — enables atomic releases and rollback).
9. Click Create Site. The site is provisioned and you're taken to its detail page.

The Site Detail Page

Once a site exists, its detail page is organised into tabs:

• Overview — domain(s), project type, web directory, PHP version, current release, SSL status, DNS instructions.
• Deploy Script — the shell script that runs on every deployment.
• Releases — the history of atomic releases, with one-click rollback.
• Environment — encrypted .env editor with sensitive-value masking and pull-from-server.
• SSL Certificates — Let's Encrypt, DNS-challenge wildcards, and custom uploads.
• Queue Workers — per-site Laravel queue workers, wrapped as Supervisor programs.
• Redirects — 301 / 302 rules added to the site's Nginx config.
• Logs — Laravel log tail with adjustable line count.

Git Integration

On the Overview tab you can connect a Git repository at any time — or change branches later. For private repos, connect a provider once under Settings → Git Repositories and Deploynix will reuse the OAuth connection (and generated deploy key) for every site. Webhooks auto-deploy on push. You can also trigger a deploy manually from the site header or schedule a deploy for a future time. For full details see Git Integration and Deployments.

Environment Variables

The Environment tab is the source of truth for your application's .env.

• Add, edit, and delete key/value pairs inline.
• Mark a variable as sensitive to hide its value in the UI (it's still written to the server).
• Use Pull from server to import an existing .env the first time you adopt a site.
• Reload PHP-FPM from the same tab after changing values so running workers pick up the new environment.
• Per-variable status badges show whether the value is synced, pending, or failed to write.

Deploy Script

Every site has a deploy script — a shell script Deploynix runs on every deployment. The default script is tailored to the project type (pull code, install Composer / npm dependencies, build assets, run Laravel migrations and config caching, etc.) and works out of the box for most apps. Custom commands you add on the Deploy Script tab run after the default script, so you can append php artisan horizon:terminate, warm caches, notify Slack, or run any other post-deploy step.

Zero-Downtime Releases & Rollback

With zero-downtime enabled, each deploy is built into a fresh releases/{timestamp} directory; traffic only switches over once the build succeeds, via an atomic symlink swap. The Releases tab lists every release and lets you roll back to any previous one with a single click. You can configure how many old releases to keep (1–20). Full details in Deployments.

Domains & SSL

Vanity Domain

Every site is auto-assigned a unique *.deploynix.cloud subdomain when it's created. It's immediately reachable over HTTPS using the server's wildcard certificate — great for testing a build before pointing real DNS at it, and the permanent address for any internal-only site.

Custom Domains

1. Add your domain on the site's Overview tab.
2. Point your DNS A/AAAA records at your server's IP (or CNAME a load-balanced alias). Deploynix shows the exact records to create.
3. Issue an SSL certificate from the SSL Certificates tab — Let's Encrypt via HTTP challenge is the default. For wildcards or domains you can't expose over HTTP, connect a DNS provider and use the DNS challenge.

You can also upload a custom certificate, and adopt existing server certs into the UI so they appear in the renewal list. See SSL Certificates.

Queue Workers

The Queue Workers tab lets you attach Laravel queue workers directly to a site. Pick a connection (Redis, database, SQS, sync), a queue name, a process count, sleep, timeout, and max-tries — Deploynix writes a Supervisor program, starts the processes, and shows their status inline. Restart workers from the same tab after each deploy, or add a php artisan horizon:terminate / php artisan queue:restart line to your deploy script to do it automatically.

Redirects

Add 301 or 302 redirects from the Redirects tab with a source path and a destination URL. Deploynix writes them into the site's Nginx config and reloads the server. Each rule has a sync status so you can see when a new rule is live.

Scheduled Deploys

You can schedule a deploy to run at a specific time instead of triggering it immediately — useful for maintenance windows or coordinating a release across multiple sites. Pending scheduled deploys can be cancelled from the same screen before they fire.

WordPress Auto-Install

Picking WordPress as the project type runs a WP-CLI bootstrap: Deploynix creates the MySQL database and user, downloads WordPress, writes wp-config.php, and shows you the generated admin username, password, and email in a credentials modal. From there you log in to /wp-admin and keep going as normal.

SSR & Node Sites

For Next.js, Nuxt.js, SvelteKit, and Angular SSR, Deploynix provisions a dedicated Node daemon under Supervisor. The deploy script runs npm install and the project's build command, then (re)starts the Node process on an allocated port; Nginx reverse-proxies the site's domain to that port. The default start command is right for each framework (e.g. npm start for Next.js, node .output/server/index.mjs for Nuxt, node build for SvelteKit) and is editable on the site.

Static SPA Sites

Static SPA project types (React, Vue, Angular, Svelte) build their bundle during deploy and serve it directly through Nginx from the build output directory. SPA client-side routing is handled by a try_files fallback to index.html.

Logs

The Logs tab tails Laravel's application log. Pick a date and adjust the line count (100 / 500 / 1000) to narrow what you see. For Nginx access and PHP-FPM error logs, use the server's web terminal or SSH in — those are intentionally not exposed in the UI to keep the site page focused on application concerns.

Deleting a Site

Deleting a site removes its files and its Nginx / PHP-FPM configuration from the server. A confirmation modal shows which database and system user are associated with the site, and lets you optionally delete the database at the same time (with a warning if the user is shared with other sites). The dedicated system user is removed if nothing else is using it. Deletion runs asynchronously; you'll be redirected back to the server page when it completes.