DEV Community

Cover image for From Zero to Deployed: The Complete Deploynix Setup Guide
Deploynix
Deploynix

Posted on • Originally published at deploynix.io

From Zero to Deployed: The Complete Deploynix Setup Guide

Whether you're deploying your first Laravel app or migrating a production stack, this guide walks you through every step — from connecting your cloud provider and Git account to provisioning a server and deploying your first site. Follow each section in order and you'll have a fully automated deployment pipeline running in under 30 minutes.

Prerequisite: An active Deploynix account at deploynix.io and accounts with DigitalOcean and GitHub (or your preferred alternatives).

Step 1: How to Connect DigitalOcean to Deploynix

Before Deploynix can provision servers on your behalf, it needs authorized access to your cloud provider. Connecting DigitalOcean takes about two minutes and requires generating a scoped API token.

Generate a DigitalOcean API Token

Log in to your DigitalOcean account and navigate to API → Tokens. Click Generate New Token, give it a descriptive name such as "Deploynix", and set the expiration to No expiry (or your preferred duration).

Required Custom Scopes

Deploynix only requests the minimum permissions needed to manage your infrastructure:

  • account — Read — validates your credentials
  • droplet — Read & Write — creates, reboots, rebuilds, and deletes servers
  • ssh_key — Read & Write — registers SSH keys for secure access
  • region — Read — lists available datacenter regions
  • size — Read — lists available droplet sizes and pricing
  • image — Read — lists available OS images

You can use a Full Access token if you prefer simplicity, but the custom scopes above are all that Deploynix requires. Your token is encrypted and stored securely — it is never exposed in plain text.

Add the Token to Deploynix

In your Deploynix dashboard, go to Settings → Provider Credentials and click Add Provider. Select DigitalOcean, give the credential a name such as "My DigitalOcean Account", paste your API token, and click Add Provider. Deploynix validates the token immediately — if the connection succeeds, you are ready to provision servers.

Step 2: How to Connect GitHub to Deploynix

With your cloud provider connected, the next step is linking your code. Connecting GitHub enables Deploynix to browse your repositories, set up deploy keys for secure SSH cloning, and create webhooks so your sites redeploy automatically on every git push.

Generate a GitHub Personal Access Token

Log in to GitHub and go to Settings → Developer settings → Personal access tokens → Fine-grained tokens. Click Generate new token, name it "Deploynix", set your preferred expiration, and under Repository access choose All repositories or select specific ones.

Required Permissions

Under Repository permissions, enable exactly these four:

  • Contents — Read & Write — clones repos and accesses code during deployment
  • Metadata — Read Only — reads repository names, branches, and default branch (selected automatically)
  • Administration — Read & Write — adds deploy keys so your server can pull code securely over SSH
  • Webhooks — Read & Write — creates and removes webhooks that trigger automatic deployments on push

Leave everything else as No access. If you prefer Classic tokens, select the repo, admin:repo_hook, and read:user scopes.

Add the Token to Deploynix

In Deploynix, go to Settings → Git Providers and click Add Git Provider. Select GitHub, name it "My GitHub", paste your Personal Access Token, and click Add Provider. Once connected, Deploynix will confirm by displaying your GitHub username and avatar.

Step 3: How to Add a Git Repository to Deploynix

A Git repository in Deploynix is the bridge between your code and your servers. You register it once, then connect it to as many sites and servers as you need — one codebase can power a staging environment and a production environment simultaneously.

Add the Repository

Go to Settings → Git Repositories and click Add Repository. Give it a friendly name such as "My Laravel App" and select the GitHub provider you just connected. Deploynix will automatically fetch your repositories — select the one you want to deploy, then select the branch (the default branch is pre-selected).

No provider? You can add a repository manually by typing the name in owner/repo format (e.g. acme/my-app) and entering the branch name directly.

Enable Auto-Deploy

Check Enable auto-deploy on push. Deploynix will automatically register a webhook on your GitHub repository. From that point on, every push to the selected branch triggers a deployment across all sites connected to this repository — no manual intervention required.

Deploy Key Setup

When you add a repository with a connected provider, Deploynix automatically generates an SSH key pair and registers the public key as a deploy key on your GitHub repository. This allows your server to securely clone code over SSH without exposing any credentials. You can also trigger a deploy key re-setup at any time from the repository's action menu.

What You Can Do After Adding a Repository

  • Connect it to multiple sites across different servers
  • Toggle auto-deploy on or off at any time
  • Change the deployment branch without recreating anything
  • View the webhook URL for manual webhook configuration
  • See exactly how many sites are currently using the repository
  • Re-setup deploy keys if a key is revoked or compromised

A practical example: point the develop branch at staging.myapp.com and the main branch at myapp.com — both managed from a single repository entry in Deploynix.

Step 4: How to Create a Server in Deploynix

With your cloud provider and Git account connected, you are ready to provision your first server. Deploynix offers seven specialized server types so you can match your infrastructure to your actual needs — from a single all-in-one server to a fully separated architecture

Choose Your Server Type

  • App Server (most popular) — Full stack in a single box: Nginx, PHP 8.4, MySQL/MariaDB/PostgreSQL, Valkey, Node.js, Composer, and Supervisor. The right starting point for Laravel, WordPress, and Statamic on a single server.
  • Web Server — Nginx, PHP 8.4, Node.js, Composer, and Supervisor — no database or cache. Designed to sit behind a load balancer and connect to an external database server.
  • Database Server — Dedicated MySQL, MariaDB, or PostgreSQL. Accepts remote connections from your Web and App servers. Ideal when multiple applications share a single database tier.
  • Cache Server — Dedicated Valkey (Redis-compatible). Handles session storage, queue backends, and application caching at scale, offloading memory pressure from your web tier.
  • Worker Server — PHP and Supervisor only, no web server, no database. Keeps heavy background processing — queue workers, scheduled tasks — completely off your web servers.
  • Meilisearch Server — Dedicated Meilisearch engine behind an Nginx reverse proxy. Accessible remotely over HTTPS for lightning-fast full-text search.
  • Load Balancer — Nginx configured for traffic distribution. Add and remove backend servers dynamically from the dashboard.

Configure and Provision

Navigate to Servers → Create Server, select your DigitalOcean credential, choose a region and droplet size, and configure the server options relevant to your server type: server name, database engine (MySQL, MariaDB, or PostgreSQL) for App and Database servers, PHP version for App, Web, and Worker servers, and IP address for Custom VPS servers. Click Create Server and Deploynix provisions everything automatically.

Managing Your Server After Provisioning

Every provisioned server gets a full management dashboard organized into tabs:

  • Overview — server status, IP address, credentials, reboot/reinstall/delete actions, and real-time CPU, RAM, and disk monitoring
  • Sites — create and manage all sites on the server with one-click deployments, zero-downtime releases, SSL, and environment variables
  • Databases — create databases and users, attach and detach privileges without SSH
  • Cron Jobs — add and manage scheduled tasks visually
  • Daemons — create and manage Supervisor background processes with one-click restarts
  • Network Rules — manage UFW firewall rules from the dashboard
  • SSH Keys — add and remove SSH keys for team access without sharing passwords
  • Logs — full provisioning log and real-time log streaming for server operations

Step 5: How to Create a Site in Deploynix

With a server running, you can deploy your first site. Deploynix supports four project types and handles the framework-specific setup automatically — directory structure, web root, database configuration, and deployment scripts are all pre-configured for each type.

Choose Your Project Type

  • Laravel — the most feature-rich option. Web directory set to /public, zero-downtime deployments with atomic symlink switching, and a fully automated pipeline: Composer install, npm build, and artisan migrate all run automatically on every deployment.
  • WordPress — installed automatically via WP-CLI. Deploynix creates the database, the database user, and configures wp-config.php for you. Requires MySQL or PostgreSQL (SQLite is not supported by WordPress).
  • Statamic — installed automatically via Composer with the web directory set to /public. Uses flat-file storage by default (no database required), with an optional database for user management and high-traffic caching. Visit /cp after installation to create your super user.
  • General PHP — a clean PHP setup with no framework assumptions. Connect any Git repository and optionally enable zero-downtime deployments for any PHP application or custom framework.

Create the Site

In your server dashboard, go to the Sites tab and click Add Site. Select your project type, confirm the web directory (auto-filled based on the type), choose a PHP version (or use the server default), connect the Git repository you registered in Step 3, enable zero-downtime deployment if applicable, configure the database connection, and click Create Site.

Auto-Generated Vanity Domain

Every site gets an instant vanity domain the moment it is created — something like swift-bright-falcon.deploynix.cloud — with a free SSL certificate already applied. Your site is accessible immediately without any DNS configuration. You can add a custom domain from the site settings at any time.

Database Connection Options

  • None — for static sites or flat-file CMS (Statamic by default)
  • SQLite — file-based database, ideal for low-traffic apps
  • Server database — a database on the same server, used by App Servers
  • Remote database server — connects to a Deploynix-managed Database Server; connection details are pre-filled automatically
  • External database — connects to any external database (AWS RDS, PlanetScale, Supabase, or any host) using custom credentials

Managing Your Site After Deployment

  • Releases — view every deployment with timestamps, roll back to any previous release with one click, and configure how many releases to retain (up to 20)
  • Environment Variables — add, edit, and delete variables from the dashboard; pull the current .env from the server at any time to keep the dashboard in sync
  • SSL Certificates — free Let's Encrypt certificates with automatic renewal; wildcard certificates for subdomains (requires a DNS provider); custom certificate installation
  • Queue Workers — create and manage Supervisor queue workers per site; configure process count and retry settings; restart workers with one click
  • Redirects — create 301 and 302 redirects visually without editing Nginx config
  • Logs — view deployment output in real time and debug without SSH

You're Ready to Deploy

You have now completed every step of the Deploynix setup: your cloud provider is connected, your Git account is authorized, your repository is registered, your server is provisioned, and your first site is live. From this point on, every push to your configured branch deploys automatically — zero-downtime, with full rollback available at any time.

As your traffic grows, Deploynix scales with you. Start by separating your database onto a dedicated Database Server, then add a Cache Server for sessions and queues, a Worker Server for background processing, and a Load Balancer to distribute traffic across multiple Web Servers — all managed from the same dashboard, with no infrastructure changes to your codebase.

Top comments (0)