
For a small WordPress site or a single low-traffic app, DigitalOcean's Basic plan at 2GB RAM / 1 vCPU is the minimum that will run comfortably — anything below that and MySQL and PHP-FPM start fighting each other for memory the moment a plugin update or a traffic spike hits. For anything you actually intend to run in production — a client site, a small SaaS, a store taking orders — size up to 4GB RAM / 2 vCPU so you have headroom for backups, staging copies, and a second or third site later.
DigitalOcean splits droplets into a few CPU families. Basic (shared CPU) droplets are the cheapest and are fine for most websites, since a typical WordPress or Laravel app spends most of its time waiting on disk and network, not burning CPU cycles. Premium droplets come in two flavors: General Purpose, which uses faster NVMe storage and newer CPUs at a slightly higher price for the same RAM/vCPU numbers, and CPU-Optimized, which is built for workloads that are genuinely CPU-bound — video processing, heavy report generation, or a busy queue worker. Unless you already know your app is CPU-bound, a Basic or Premium General Purpose droplet is the right starting point, and you can always resize the droplet up later from the DigitalOcean control panel without rebuilding anything.
Choose Ubuntu 22.04 (LTS) x64 as the image. It is the distribution CloudStick and most modern control panels are built and tested against, it gets security patches through April 2027, and it has the widest compatibility with PHP, Nginx, and MariaDB packages you will need later. Skip newer non-LTS releases and skip CentOS-based images unless you have a specific reason to need them — LTS releases exist specifically so production servers are not forced into disruptive upgrades every six months.
For the datacenter region, pick whichever DigitalOcean region is physically closest to the majority of your visitors, not the one closest to you personally. A site serving a US audience but hosted in Singapore will add real, measurable latency to every request, regardless of how fast the server itself is. If your audience is genuinely global, a CDN in front of the origin server matters more than which single region you pick — but the origin should still sit near your largest visitor segment or your admin/checkout traffic, since that traffic can't be cached at the edge.
Add an SSH key during droplet creation instead of letting DigitalOcean email you a root password. Password-based root login on a public IP gets probed by automated bots within minutes of going live, while a properly generated SSH key pair cannot be brute-forced in any practical timeframe. If you don't already have a key pair on your machine, generate one before you even open the DigitalOcean dashboard.
ed25519 keys are shorter, faster to verify, and considered at least as secure as RSA-4096 by current standards — there's no good reason to default to RSA anymore. Paste the public key into DigitalOcean's "New SSH Key" field during droplet creation once, and every droplet you create afterward can reuse the same saved key with one click.
With an account created and billing added, click "Create" → "Droplets" in the DigitalOcean dashboard. Select the Ubuntu 22.04 (LTS) x64 image, choose your region, pick the Basic plan at 2GB/1vCPU or 4GB/2vCPU depending on the sizing decision from step one, and select the SSH key you just added under Authentication instead of a root password. Give the droplet a hostname that actually identifies it — "client-acme-prod" is far more useful six months from now than the auto-generated default.
Click "Create Droplet" and DigitalOcean provisions it in roughly 55 seconds. Once it shows "Active" in the dashboard, copy the public IPv4 address shown next to it — that IP is everything you need for the next step, and it's also what you'll hand to CloudStick when you connect the server later.
Connect with the IP you just copied. Because you added the key at creation time, DigitalOcean bakes it into the droplet's authorized_keys automatically — there is no password to type and no separate step to enable key auth.
If the connection drops or hangs instead of prompting for the fingerprint, the droplet is usually still finishing boot — wait thirty seconds and try again before assuming something is misconfigured. Once you're in, `uptime` confirms the box is alive and shows how long it has been running, `free -h` and `df -h` confirm the RAM and disk you paid for actually match what you selected, and `apt update` confirms outbound network access works and refreshes the package index for anything you install afterward. That is the full extent of verification a fresh droplet needs — you don't need to run a benchmark or stress test to confirm a droplet is healthy.
This is the point where most beginner guides leave you to figure out Nginx, PHP-FPM, MariaDB, and a firewall by hand — CloudStick replaces all of that with one step. In the CloudStick dashboard, click "Add Server," paste in the droplet's IP, and use Direct Install: CloudStick connects over the same SSH key you already set up, installs the full stack unattended, and adds the server to your account when it finishes. If your environment doesn't allow inbound SSH from CloudStick's connector, the dashboard also gives you a manual install command you copy and paste into the same SSH session from the previous step — same result, run from your side instead of theirs.
Either path lands you on Ubuntu 22.04 running Nginx 1.24 (nginx-cs), Apache 2.4.53 (apache2-cs) on port 81 for PHP handling, PHP-FPM, MariaDB 10.6, Redis, and a CSF firewall pre-configured with sane defaults — all of it already wired together and already reporting into the dashboard. From here, creating a website, issuing an SSL certificate, creating a database, and scheduling backups are all clicks in the CloudStick dashboard, not commands typed against a terminal you have to keep re-opening. That is the actual point of the exercise: the SSH session you just used gets you a verified, connected server once, and then the terminal is optional for everything that comes after — new sites, PHP version switches, SSL renewals, and backup schedules are all managed from the dashboard on a per-server flat rate with no per-site fees added on top.

