Servers - Deploynix Docs

Servers

Provision and manage servers across DigitalOcean, Hetzner, Vultr, Linode, AWS, or any existing machine you can reach by SSH.

Overview

A server in Deploynix is a virtual machine that has been set up with a full web stack and is actively managed by the dashboard. You pick a cloud provider and a server type, and Deploynix installs, configures, and hardens everything for you. After that, every action — adding sites, databases, cron jobs, daemons, SSH keys, firewall rules, SSL certificates — happens from the server's detail page. You never need to SSH in to get work done, but a web terminal is there when you want to.

Server Types

Each server has a single type chosen at creation. The type decides which software is installed and which features appear on the server's detail page. You cannot change the type after provisioning, so pick deliberately.

Type Installed Stack Typical Use
App Server Nginx, PHP, a database (MySQL / MariaDB / PostgreSQL), Valkey, Node.js, Composer, Supervisor, Certbot Single-box Laravel / WordPress / PHP applications
Web Server Nginx, PHP, Node.js, Composer, Supervisor, Certbot (no local DB / cache) Stateless web tier paired with dedicated Database and Cache servers
Database Server MySQL, MariaDB, or PostgreSQL with remote access enabled Dedicated database host shared by one or more web tiers
Cache Server Valkey (Redis-compatible) with remote access Shared cache, sessions, queue broker
Worker Server PHP, Composer, Supervisor Horizon / queue workers / scheduled jobs off the web tier
Meilisearch Server Meilisearch behind an HTTPS reverse proxy Full-text search for your applications
Load Balancer Nginx load balancer Distribute traffic across multiple App or Web servers

Supported Providers

Connect a provider under Settings → Server Providers before creating your first server. For required scopes and API key setup, see Provider Permissions.

DigitalOcean DigitalOcean
Vultr Vultr
Linode Linode
Hetzner Hetzner
AWS AWS
Custom Server

Custom Server is the escape hatch: if you already have a VM — bare metal, a provider we don't integrate with, a home lab — add it by IP and copy the provided SSH key into the machine. Deploynix will then provision it exactly like a cloud-born server.

Creating a Server

  1. Open Servers from the dashboard and click Create Server.
  2. Choose a server type from the grid.
  3. Pick the cloud provider and the saved credential to use.
  4. Select a region near your users and a server size. Regions and sizes load dynamically from the provider — pricing is shown inline.
  5. Give the server a name.
  6. Configure the software stack (fields shown depend on the type):
    • PHP version — 8.4, 8.3, 8.2, 8.1, or 8.0 (shown for App, Web, Worker).
    • Database — MySQL, MariaDB, or PostgreSQL (required for App and Database).
    • Web server — Nginx or Apache (shown for App and Web).
  7. Click Create Server. You'll be redirected to the server page where a live progress log streams provisioning output.

Provisioning Time

Provisioning typically takes 5–10 minutes. You'll receive a notification when the server is ready.

What Happens During Provisioning

Every server type follows the same high-level pipeline. Each phase streams its output to the logs tab, so you can watch it live.

  1. Create the cloud resource — call the provider API to spin up the VM (skipped for Custom servers).
  2. Wait for SSH — poll for reachability up to five minutes.
  3. Create the deploynix user — a non-root user becomes the default for all future commands.
  4. System setup — disable unattended-upgrades, wait for apt locks, install base packages, configure a swap file.
  5. Install the stack — Nginx, PHP (Ondrej PPA), database engine, Valkey, Node.js, Composer, WP-CLI, Supervisor, Certbot — each only if the server type requires it.
  6. Install the monitoring agent — if monitoring is enabled for the organization.
  7. Install the vanity wildcard certificate — gives the server an immediate HTTPS subdomain (see below).
  8. Security hardening — SSH config, firewall defaults.
  9. Mark as active — the server transitions to active and you receive a notification.

The Server Detail Page

Once a server is active, its detail page shows a set of tabs tailored to the type. You will only see the tabs that apply to your server.

  • Overview — provider, region, IP, status, uptime, installed software, quick actions.
  • Sites (App, Web) — create and manage hosted applications. See Sites.
  • Databases (App, Database) — databases and database users. See Databases.
  • Backups (Database) — scheduled and on-demand backups to external storage.
  • Cron Jobs (App, Web, Worker) — scheduled tasks managed as crontab entries.
  • Daemons (App, Web, Worker) — long-running processes under Supervisor.
  • Load Balancing (Load Balancer) — upstream groups and backend servers.
  • Network Rules — firewall rules by port, protocol, and source IP.
  • SSH Keys — public keys authorised on the server.
  • Monitoring — CPU, memory, disk, load average, and alerts.
  • Logs — provisioning and system logs streamed in real time.
  • Settings — rename, restart, reprovision, or delete the server.

SSH Access

Two ways to get a shell on your server:

  • Web terminal — a full interactive terminal in the browser, no client setup, no extra credentials. Input, output, and resize are proxied over a WebSocket so it feels native.
  • Your own SSH client — upload your public key under the SSH Keys tab and connect as the deploynix user from your local machine. Your plan limits how many keys you can add.

Cron Jobs

Schedule recurring tasks from the Cron Jobs tab:

  1. Click Add Cron Job.
  2. Enter the command and a cron expression, or pick a preset frequency (every minute, hourly, daily, etc.).
  3. Choose the user the command should run as.
  4. Click Save. Deploynix writes the entry into the user's crontab on the server.

A common use: a single * * * * * php artisan schedule:run entry that hands off to Laravel's scheduler.

Daemons

Daemons are long-running processes managed by Supervisor. Use them for anything that needs to stay up between deployments.

  1. Open the Daemons tab and click Add Daemon.
  2. Enter the command, working directory, user, and the number of processes to run.
  3. Click Save. Deploynix writes the Supervisor program file, reloads Supervisor, and starts the processes.
  4. Use the row's Restart button after you change environment variables or deploy new code.

Common Use Cases for Daemons

  • • Laravel queue workers (php artisan queue:work)
  • • Laravel Horizon (php artisan horizon)
  • • Laravel Reverb or other WebSocket servers
  • • SSR Node processes for Next.js / Nuxt / SvelteKit sites
  • • Any long-running background worker

Network Rules (Firewall)

Under Network Rules you can add allow or deny rules by port, protocol, and source IP (or Any). Deploynix applies sensible defaults during provisioning — SSH, HTTP, HTTPS, plus anything the server type needs — and you add rules for custom ports on top of that.

Monitoring & Health Alerts

When the monitoring agent is installed, every server reports snapshots of:

  • CPU usage
  • Memory usage
  • Disk usage
  • Load average

Snapshots drive the Monitoring tab charts and feed the health alert engine. When a metric crosses its threshold, an alert is created with a severity (low, medium, high, critical) and you receive a notification. Alerts auto-resolve when the metric recovers, or you can dismiss them manually.

Vanity Wildcard Certificate

Every App, Web, Database, Cache, and Meilisearch server gets a unique subdomain under *.deploynix.cloud at provisioning time, with a wildcard TLS certificate already installed. That means you can open the server over HTTPS the moment it's ready — before you have DNS records for your real domain. It's also how the built-in admin panel on the server stays secure.

Restart, Reprovision, and Delete

From the server's Settings you can:

  • Restart — reboot the VM or restart individual services (Nginx, PHP-FPM, database, Supervisor).
  • Reprovision — rerun the installation pipeline if something drifted or failed mid-provisioning.
  • Delete — remove the server from Deploynix. For cloud-provider servers, you can optionally destroy the underlying VM through the provider API at the same time.