Skip to the content.

Examples & Use Cases

Real-world examples and common use cases for Simple VPS Provisioner.

Table of Contents


Quick Start Examples

Fresh Drupal Site

The simplest way to get started with a new Drupal site:

sudo svp setup mysite.com \
  --cms drupal \
  --le-email admin@mysite.com

What you get:

Time: 5-10 minutes

Access:


Fresh WordPress Site

sudo svp setup myblog.com \
  --cms wordpress \
  --le-email admin@myblog.com

What you get:

Next steps:

# Complete installation
https://myblog.com/wp-admin/install.php

Production Deployments

Deploy from Git Repository

Deploy an existing Drupal site from GitHub:

sudo svp setup production.mysite.com \
  --cms drupal \
  --git-repo git@github.com:mycompany/mysite.git \
  --git-branch main \
  --le-email devops@mycompany.com

Perfect for:

Repository structure supported:

mysite/
├── composer.json
├── web/
│   ├── index.php
│   └── sites/default/
├── config/sync/
└── drush/drush.yml

Import Existing Database

Migrate a site with an existing database:

sudo svp setup mysite.com \
  --cms drupal \
  --git-repo git@github.com:mycompany/mysite.git \
  --db /home/admin/mysite-backup-2024-01-15.sql.gz \
  --le-email admin@mysite.com

Steps:

  1. Upload database backup to server
  2. Run svp with -db flag
  3. Database is imported automatically
  4. Site is ready to use

Supported formats:

Important: Don’t forget to sync files:

rsync -avz user@old-server:/var/www/mysite/web/sites/default/files/ \
  /var/www/mysite.com/web/sites/default/files/

Multi-Environment Setup

Production, staging, and development on one server:

sudo svp setup mysite.com \
  --cms drupal \
  --extra-domains "staging.mysite.com,dev.mysite.com" \
  --git-repo git@github.com:mycompany/mysite.git \
  --le-email devops@mycompany.com

Creates:

Each environment has:

Switching branches:

# Staging → develop branch
cd /var/www/staging.mysite.com
sudo -u admin git checkout develop

# Dev → feature branch
cd /var/www/dev.mysite.com
sudo -u admin git checkout feature/new-feature

Protect non-production with Basic Auth:

# Password-protect staging
sudo svp auth staging.mysite.com enable \
  --username team \
  --password stagingPass2024

# Password-protect dev
sudo svp auth dev.mysite.com enable \
  --username dev \
  --password devPass2024

Password-Protected Staging Site

Set up a staging environment with Basic Authentication to prevent public access:

# Step 1: Provision staging site with SSL
sudo svp setup staging.mysite.com \
  --cms drupal \
  --git-repo git@github.com:mycompany/mysite.git \
  --git-branch develop \
  --le-email admin@mysite.com

# Step 2: Enable Basic Authentication
sudo svp auth staging.mysite.com enable \
  --username client \
  --password previewAccess2024

What you get:

Common scenarios:

Client Preview:

# Set up preview site
sudo svp setup preview.mysite.com \
  --cms drupal \
  --db /path/to/production-backup.sql.gz \
  --le-email admin@mysite.com

# Protect with auth
sudo svp auth preview.mysite.com enable \
  --username client \
  --password ClientView123

# Share with client:
# URL: https://preview.mysite.com
# Username: client
# Password: ClientView123

Development Environment:

# Set up dev site
sudo svp setup dev.mysite.com --cms drupal

# Enable authentication interactively
sudo svp auth dev.mysite.com enable
# Prompts for username and password

# Check if enabled
sudo svp auth dev.mysite.com check

Remove Protection When Ready:

# Disable auth when moving to production
sudo svp auth staging.mysite.com disable

Development Workflows

Local to Production

Step 1: Local Development

Develop locally with DDEV, Lando, or Docker:

# Your local Drupal site
~/Sites/mysite/

Step 2: Push to Git

cd ~/Sites/mysite
git add .
git commit -m "Ready for production"
git push origin main

Step 3: Deploy to VPS

sudo svp setup mysite.com \
  --cms drupal \
  --git-repo https://github.com/mycompany/mysite.git \
  --le-email admin@mysite.com

Step 4: Import Database

# Export from local
drush sql-dump --gzip > mysite-db.sql.gz

# Upload to server
scp mysite-db.sql.gz admin@mysite.com:/home/admin/

# Import on server
cd /var/www/mysite.com
drush-mysite.com sql-drop -y
zcat /home/admin/mysite-db.sql.gz | drush-mysite.com sql-cli

# Sync files
rsync -avz ~/Sites/mysite/web/sites/default/files/ \
  admin@mysite.com:/var/www/mysite.com/web/sites/default/files/

Feature Branch Testing

Test a feature branch on a dedicated environment:

sudo svp setup feature-xyz.mysite.com \
  --cms drupal \
  --git-repo git@github.com:mycompany/mysite.git \
  --git-branch feature/xyz \
  --le-email admin@mysite.com

After testing, tear down:

# Remove site
sudo rm -rf /var/www/feature-xyz.mysite.com

# Remove database
sudo mysql -e "DROP DATABASE drupal_feature_xyz_mysite_com;"
sudo mysql -e "DROP USER 'drupal_feature_xyz_mysite_com'@'localhost';"

# Remove SSL certificate
sudo certbot delete --cert-name feature-xyz.mysite.com

Migration Scenarios

Migrate from Shared Hosting

Step 1: Backup Current Site

On shared host:

# Files
tar -czf mysite-files.tar.gz public_html/

# Database
mysqldump -u username -p database_name | gzip > mysite-db.sql.gz

Step 2: Download Backups

scp user@shared-host:mysite-files.tar.gz ./
scp user@shared-host:mysite-db.sql.gz ./

Step 3: Upload to VPS

scp mysite-*.tar.gz admin@vps-ip:/home/admin/
scp mysite-db.sql.gz admin@vps-ip:/home/admin/

Step 4: Provision Site

# On VPS
sudo svp setup mysite.com \
  --cms drupal \
  --db /home/admin/mysite-db.sql.gz \
  --le-email admin@mysite.com

Step 5: Extract Files

cd /var/www/mysite.com/web/sites/default
sudo tar -xzf /home/admin/mysite-files.tar.gz
sudo chown -R admin:www-data files/
sudo chmod -R 775 files/

Step 6: Update DNS

Point DNS to new VPS:

A    mysite.com    NEW_VPS_IP

Migrate from Another VPS

Using rsync for minimal downtime:

Step 1: Provision New Server

sudo svp setup mysite.com \
  --cms drupal \
  --ssl=false

Step 2: Sync Files (Incremental)

rsync -avz --delete \
  user@old-vps:/var/www/mysite/web/sites/default/files/ \
  /var/www/mysite.com/web/sites/default/files/

Step 3: Export/Import Database

On old server:

drush sql-dump --gzip > mysite-latest.sql.gz

On new server:

scp user@old-vps:mysite-latest.sql.gz /tmp/
cd /var/www/mysite.com
zcat /tmp/mysite-latest.sql.gz | drush-mysite.com sql-cli

Step 4: Final Sync (Downtime)

Put old site in maintenance mode, final sync:

drush @old pm-enable maintenance_mode
rsync -avz --delete \
  user@old-vps:/var/www/mysite/web/sites/default/files/ \
  /var/www/mysite.com/web/sites/default/files/

Step 5: Enable SSL

# Add SSL using update-ssl command
sudo svp update-ssl mysite.com enable --le-email admin@mysite.com

Step 6: Switch DNS

Update DNS to point to new server.


Advanced Configurations

Custom PHP Version

Use PHP 8.4 for latest features:

sudo svp setup mysite.com \
  --cms drupal \
  --php-version 8.4 \
  --le-email admin@mysite.com

Upgrade PHP Version

Upgrade existing site:

sudo svp php-update mysite.com \
  --php-version 8.4

Manage SSL Certificates

Add or update SSL certificates for existing sites:

# Enable SSL on a site that was set up without it
sudo svp update-ssl mysite.com enable --le-email admin@mysite.com

# Check SSL certificate status
sudo svp update-ssl mysite.com check

# Renew an existing certificate
sudo svp update-ssl mysite.com renew

# Disable SSL
sudo svp update-ssl mysite.com disable

Common use cases:


Monorepo Structure

Repository with Drupal in subdirectory:

monorepo/
├── backend/          # Drupal here
│   ├── composer.json
│   └── web/
├── frontend/         # React app
└── docs/
sudo svp setup mysite.com \
  --cms drupal \
  --git-repo https://github.com/mycompany/monorepo.git \
  --drupal-root "backend" \
  --le-email admin@mysite.com

HTTP Only (Internal Network)

For internal tools without SSL (simply omit –le-email):

sudo svp setup internal.mycompany.local \
  --cms drupal \
  --firewall=false

Note: SSL is disabled by default when –le-email is not provided.


Custom Document Root

Non-standard docroot:

sudo svp setup mysite.com \
  --cms drupal \
  --docroot "public_html" \
  --le-email admin@mysite.com

WordPress Examples

Basic WordPress

sudo svp setup myblog.com \
  --cms wordpress \
  --le-email admin@myblog.com

WordPress from Git

sudo svp setup myblog.com \
  --cms wordpress \
  --git-repo https://github.com/mycompany/wp-site.git \
  --le-email admin@myblog.com

WordPress with Database Import

sudo svp setup myblog.com \
  --cms wordpress \
  --db /home/admin/wp-backup.sql.gz \
  --le-email admin@myblog.com

After import:

cd /var/www/myblog.com
sudo -u admin wp search-replace 'http://old-domain.com' 'https://myblog.com'

Troubleshooting Examples

Test DNS Before SSL

# Check if DNS is configured
dig +short mysite.com

# Should return your server IP
123.45.67.89

# Test without SSL first (just omit --le-email)
sudo svp setup mysite.com --cms drupal

# Add SSL later using update-ssl
sudo svp update-ssl mysite.com enable --le-email admin@mysite.com

# Or using certbot directly
sudo certbot --nginx -d mysite.com --non-interactive --agree-tos --email admin@mysite.com

Reprovision with Fresh Database

Clean slate with new credentials:

sudo svp setup mysite.com --cms drupal

When prompted:

Directory /var/www/mysite.com is not empty
Delete and reprovision? [y/N]: y

Result:


Reprovision Keeping Database

Keep credentials, clear tables:

sudo svp setup mysite.com --cms drupal --keep-existing-db

Result:


Best Practices

1. Always Test Without SSL First

# Step 1: Test HTTP (omit --le-email)
sudo svp setup example.com --cms drupal

# Step 2: Verify site works
curl -I http://example.com

# Step 3: Add SSL using update-ssl
sudo svp update-ssl example.com enable --le-email admin@example.com

# Or using certbot directly
sudo certbot --nginx -d example.com

2. Use Git for All Production Sites

# Benefits:
# - Version control
# - Easy rollbacks
# - Team collaboration
# - CI/CD integration

sudo svp setup example.com \
  --cms drupal \
  --git-repo git@github.com:company/site.git \
  --le-email admin@example.com

3. Separate Environments

# Never mix production and development
sudo svp setup example.com \
  --cms drupal \
  --extra-domains "staging.example.com"

4. Regular Backups

# Automated backup script
#!/bin/bash
DOMAIN="example.com"
BACKUP_DIR="/backups/$(date +%Y%m%d)"

mkdir -p $BACKUP_DIR

# Database
drush-$DOMAIN sql-dump --gzip > $BACKUP_DIR/$DOMAIN-db.sql.gz

# Files
tar -czf $BACKUP_DIR/$DOMAIN-files.tar.gz \
  /var/www/$DOMAIN/web/sites/default/files

# Code (if not in Git)
tar -czf $BACKUP_DIR/$DOMAIN-code.tar.gz \
  --exclude='sites/default/files' \
  /var/www/$DOMAIN

More Help


← Back to Home Documentation →