How to Set Up Cloudways for Small Teams

If you manage one to five websites and want managed cloud hosting without a DevOps hire, this tutorial gets you there. By the end, you'll have a Cloudways account connected to a cloud provider, at least one live server running, and a WordPress site deployed — ready for your team to use.

What You Need Before You Start

No surprises mid-setup. Check these off first.

You don't need SSH knowledge to complete the core setup. It helps later, but nothing in this tutorial requires it.

What You'll Have When You're Done

This isn't a vague "your site will be live" promise. Here's the precise end state:

• A Cloudways account verified and billing active
• One cloud server provisioned on your chosen provider (DigitalOcean, Vultr, AWS, or another supported option)
• One WordPress application deployed on that server
• Your domain pointed to the server's IP address
• SSL certificate installed and HTTPS working
• At least one team member invited with an appropriate role

Your server will be running, your site will be accessible via your domain over HTTPS, and your team will have login access scoped to what they actually need. That's a complete, functional setup — not a half-finished environment you'll have to wrestle with later.

Start Your Cloudways Setup

Steps 1–3: Getting Your Team Set Up on Cloudways

Before anything else, you need three things working correctly: an account that reflects how your team actually operates, a server that fits your workload without over-spending, and at least one live application you can hand off to someone else on the team. These first three steps carry most of the setup weight. Get them right and the rest is configuration.

Step 1: Create Your Account and Configure Team Access

Go to Cloudways and sign up. The registration form is straightforward — email, password, basic details. You'll land on a free trial without entering a card number, which is useful for poking around before committing.

Once you're in, the first thing worth doing is not launching a server. It's setting up team access.

Cloudways uses a role-based system under Team Management (found in the top-right account menu). For a small team managing one to five sites, you typically need two roles:

• Owner — full access to billing, server settings, app deployments, and team management
• Project User — scoped access to specific applications only, no billing visibility

Here's why this matters early: if you add team members after servers and apps are already live, you end up scrambling to reassign permissions and figure out what each person can see. Setting roles first means your developer, your client, or your VA drops into exactly the right access level from day one.

How to verify Step 1 is done correctly:

• Navigate to Account > Team Management
• Confirm at least one additional user has been invited with the correct role
• Log in from a separate browser or incognito window using that user's credentials and confirm they can only see what they should

One thing to double-check: Project Users can be limited to specific applications. If you're managing client sites, this is how you keep one client from accidentally seeing another's environment.

Step 2: Choose Your Server (Cloud Provider + Plan)

This is the decision that trips most small teams up. Cloudways sits on top of five cloud providers — DigitalOcean, Linode (now Akamai), Vultr, AWS, and Google Cloud. You're not locked into one forever, but migrating later is annoying, so spend five minutes thinking this through now.

For most small teams managing one to five WordPress or PHP sites, DigitalOcean or Vultr is the practical starting point. They're cheaper than AWS and GCP for equivalent resources, and the control panel experience is nearly identical regardless of which provider you choose. Linode is a reasonable alternative if DigitalOcean availability is an issue in your target region.

When you click Add Server , you'll configure:

• Cloud provider
• Server size (RAM, storage, bandwidth)
• Data center location
• Server label (name it something descriptive — you'll thank yourself later)

On server size: A 1GB RAM instance handles light traffic for one or two small sites. If you're running three to five sites with some WooCommerce or dynamic content, start at 2GB. You can scale vertically inside Cloudways, but it requires a brief restart, so getting close to right upfront saves interruption.

On location: Pick the data center closest to where most of your visitors are, not where you are. If you're a US-based team running a UK-facing site, pick London.

How to verify Step 2 is done correctly:

• Your server shows status Running (green indicator) on the Servers dashboard
• The server label and cloud provider match what you intended — it sounds obvious, but it's easy to click through too fast
• SSH access is possible if your team uses it (Cloudways provides SSH credentials under Server > Master Credentials )

One thing worth knowing: a single Cloudways server can host multiple applications. You don't need a new server per site. That's one of the actual advantages for small teams — your five client sites can live on one well-sized server and share its resources efficiently.

If you're still weighing whether Cloudways is the right platform at all, the Cloudways review at Toolvoro breaks down what works and what doesn't for smaller operations specifically.

Step 3: Deploy Your First Application

With the server running, you're ready to add an application. In Cloudways, an "application" is essentially a site installation — one application per website.

Click Add Application from the server detail screen. You'll choose:

• Application type — WordPress, WooCommerce, PHP, Laravel, Magento, and others
• Application name — again, name it clearly; something like clientname-prod beats app1
• PHP version — for new WordPress installs, PHP 8.1 or 8.2 is the safe choice unless a specific plugin requires otherwise

The deployment takes about a minute. Once it's done, Cloudways auto-provisions a staging URL so you can reach the site immediately without touching DNS.

What to do right after deployment:

• Go to Application > Access Details and copy the temporary URL, admin username, and password
• Log into WordPress (or your CMS) and confirm it loads cleanly
• Check Application > SSL Certificate — Cloudways integrates Let's Encrypt directly, so you can enable HTTPS before you even point your domain

The SSL step is easy to skip and easy to forget. If a team member launches the site before SSL is configured on the real domain, it creates a redirect mess later. Handle it now.

How to verify Step 3 is done correctly:

• The application shows Running status on your server dashboard
• You can reach the staging URL and log into the CMS backend without errors
• SSL is either active on the staging URL or queued for the real domain
• The application name makes sense to anyone on the team, not just whoever set it up

A note on workflow for teams: Cloudways supports cloning applications, which matters more than it sounds. Once your first application is configured the way you like — PHP version, SSL, caching settings — you can clone it as a starting template for the next site. Small teams running multiple client builds save real time this way instead of reconfiguring from scratch each time.

What You've Actually Accomplished So Far

Three steps in, you have a functional foundation:

• Team access is scoped correctly so the right people see the right things
• A server is live, sized reasonably for your workload, and located near your audience
• At least one application is deployed and reachable

Nothing here is irreversible. Cloudways lets you scale server resources, change application settings, and add team members as your needs shift. But starting with structure — roles before servers, clear naming, SSL early — avoids the kind of technical debt that causes real problems when you're managing five sites instead of one.

Steps 4 through 6 cover domain mapping, backup configuration, and the team handoff process. If you're also thinking about how Cloudways stacks up against other managed hosts before going further, Cloudways vs alternatives gives a direct comparison worth reading.

Start Your Cloudways Free Trial

Step 4: Add Your First Application

Once your server is running, Cloudways drops you into the server detail screen. From here, go to the Applications tab and click Add Application .

You'll see a dropdown of application types. For most small teams, that means WordPress — but Cloudways also supports WooCommerce, PHP, Laravel, and a few others. Pick the one that matches your site.

What to fill in:

• Application name (use something descriptive — you'll thank yourself when managing multiple sites later)
• Application username and password (these are for your app's database and SFTP, not your Cloudways login)
• Choose the server you just set up

Hit Add Application and wait about 60–90 seconds. Cloudways provisions the full stack: web server, database, PHP, and all the supporting services.

Why this step matters more than it looks: Cloudways separates servers from applications intentionally. One server can host multiple WordPress installs, each with its own credentials, file structure, and staging environment. For a team managing 2–4 sites, this architecture means you're not paying for three separate servers — just one well-sized one with multiple apps on it.

How to verify it worked:

• Click into the application from the Applications tab
• You should see the Access Details panel with your app URL, SFTP credentials, and database info
• Open the temporary app URL in your browser — a default WordPress install (or your chosen app's placeholder) should load

If it doesn't load within 2–3 minutes, check the server status indicator in the top bar. Green means it's running. Anything else, give it another minute before troubleshooting.

Step 5: Point Your Domain and Enable SSL

This is the step people rush and then regret. Take the extra five minutes here — it saves a support headache later.

First, add your domain inside Cloudways:

• Open your application
• Go to Domain Management
• Enter your primary domain (e.g., yoursite.com) and add www.yoursite.com as an additional domain if you want both to resolve

Save the changes. Cloudways doesn't manage your DNS registrar — you'll still need to log into wherever your domain is registered (GoDaddy, Namecheap, Cloudflare, wherever) and update the A record to point to your server's public IP address. You'll find that IP on your server's main detail screen.

DNS propagation typically takes anywhere from a few minutes to a few hours. While you're waiting, don't skip ahead to SSL — the certificate won't issue correctly until the domain is actually resolving to your server.

Once DNS has propagated, enable SSL:

• Go to SSL Certificate in the application menu
• Select Let's Encrypt (it's free and renews automatically)
• Enter your domain, check the wildcard option if you want www covered, and click install

The certificate installs in under a minute. After it's active, force HTTPS by toggling Redirect HTTP to HTTPS on the same screen.

Why this order matters: Skipping the domain verification before SSL is the single most common setup mistake on Cloudways. Let's Encrypt verifies domain ownership via HTTP, so if your DNS isn't pointing at the server yet, the certificate request fails. Then you're stuck waiting for DNS anyway, but now you've also got a failed SSL attempt to clear.

How to verify:

• Visit your domain in a browser
• The padlock icon should appear in the address bar
• Try visiting the http:// version — it should redirect automatically to https://

If you see a certificate warning instead of the padlock, wait another 10–15 minutes and try again. Caching at the browser or DNS level can create a brief false negative.

Step 6: Configure Backups and Team Access

Most small teams set up the server, get the site live, and then move on — leaving backups and access controls as something they'll "get to later." Don't do that. These two settings take under ten minutes and are the difference between a recoverable mistake and a very bad afternoon.

Backups

Cloudways includes automated backups built into every plan. They're not on by default in the way you might expect, so you need to configure the frequency manually.

To set up backups:

• Go to your server's Backups tab (this is at the server level, not the application level)
• Set the backup frequency — daily is the right choice for active sites
• Choose a backup retention period (1–4 weeks is practical for most small teams)
• Pick a backup time during off-peak hours for your audience

Cloudways stores backups on your server's local disk by default. If you want off-server backups (which you should, especially for client sites), connect an external storage provider under Server Management > Backup Offsite Storage . Cloudways supports Amazon S3, Google Cloud Storage, Dropbox, and a few others.

One thing worth noting: restoring from backup on Cloudways is genuinely straightforward. You go to the Backups tab, pick a restore point, and confirm. There's no ticket submission or waiting for support. For a small team without a dedicated sysadmin, that matters.

How to verify backups are configured:

• Check the Backups tab after 24 hours — you should see a completed backup entry with a timestamp
• If you're using offsite storage, confirm the connection test passes when you save the settings

Team Access

If you're the only person who ever touches these servers, you can skip ahead. But most small teams have at least one developer, a designer, or a client stakeholder who needs some level of access.

Cloudways handles this at the account level, not the server level. Go to Account > Users and invite team members by email. You can assign one of two roles:

• Account Owner — full access to everything, including billing
• Account User — can manage applications and servers but can't touch billing or account settings

For most teams, everyone except the billing contact should be an Account User. You don't want a developer accidentally changing payment details.

For developers who need file-level or database access without a Cloudways account, use SFTP credentials and database credentials from the Access Details section of each application. Those can be shared independently.

How to verify:

• Send yourself a test invite to a secondary email if you want to confirm the onboarding flow works
• Log in as the invited user and confirm the access level matches what you intended
• Check that sensitive sections (like billing) aren't visible to Account Users

Before Moving to the Next Phase

At this point, your Cloudways setup covers the essentials: a running server, a deployed application, a domain with SSL, automated backups, and the right people with the right access. That's a solid foundation.

A few things worth checking before you consider the setup complete:

• PHP version matches what your application requires (check under Application Settings > PHP Settings )
• Caching is configured — Cloudways includes Varnish, Nginx, and Memcached depending on your stack; the Manage Services tab shows what's running
• Your staging environment is ready if you need one — Cloudways has a one-click staging clone under each application

If you're thinking about how to automate recurring tasks like deployments or cache clearing, the Cloudways automation strategy guide covers that specifically for smaller teams who want to reduce manual work without overbuilding their workflow.

Not sure Cloudways is the right fit after going through the setup? The Cloudways vs. alternatives comparison breaks down where it wins and where other platforms are a better call.

Troubleshooting Your Cloudways Setup

Even a clean setup hits snags. Most issues small teams run into aren't mysterious — they repeat across the same handful of failure points. Here's what actually goes wrong and how to fix it fast.

Server Won't Start or Gets Stuck on "Launching"

This one causes panic but rarely means something is seriously broken.

What's happening: The cloud provider (DigitalOcean, Vultr, AWS, etc.) is taking longer than expected to provision the server, or a region is temporarily under load.

Fix:

• Wait 5–10 minutes before doing anything. Refreshing or clicking Launch again can create duplicate servers.
• If it's still stuck after 15 minutes, open a Cloudways support chat. Do not attempt to delete and relaunch without confirming the first server didn't provision silently — you could get billed for both.
• Check the provider's status page directly (e.g., DigitalOcean's status.digitalocean.com) to rule out a regional outage.

Application URL Shows a Default Server Page Instead of Your Site

You launched the server, added the application, and opened the URL — but it's showing a generic Apache or Nginx page, not your WordPress install.

What's happening: You're hitting the server IP or a misconfigured domain, not the application's staging URL.

Fix:

• Navigate to Application Management > Access Details and copy the exact staging URL Cloudways provides. Use that URL directly, not the raw server IP.
• If you've already pointed a custom domain, double-check the domain is entered under Application Management > Domain Management — not just at your registrar.
• DNS changes take time. Use whatsmydns.net to verify propagation before assuming something is broken on the Cloudways side.

SSL Certificate Fails to Install

Free Let's Encrypt SSL is one click in theory. In practice, it fails for predictable reasons.

Common causes and fixes:

• Domain not yet pointing to the server: SSL validation requires the domain to resolve to your server IP. If DNS hasn't propagated, the certificate request will fail silently or return an error. Confirm DNS first, then retry.
• www vs. non-www mismatch: Make sure both variants are added under Domain Management, or pick one and set up a redirect. Let's Encrypt will fail if the domain it's trying to validate doesn't resolve correctly.
• Rate limit hit: Let's Encrypt allows a limited number of certificate requests per domain per week. If someone on your team retried installation repeatedly, you may be temporarily blocked. The error message will say so. Wait and retry after the reset period.

After a successful install, validate by visiting your URL with https:// and checking the padlock. If you see a mixed content warning instead, there's likely a hardcoded http:// URL somewhere in your WordPress database — use a plugin like Better Search Replace to update it.

SFTP or SSH Connection Refused

Your developer needs server access and can't connect.

What's happening: Either the credentials are wrong, the SSH access isn't enabled, or there's an IP restriction blocking the connection.

Fix:

• Go to Server Management > Master Credentials and confirm you're using the correct server-level username and password (not your Cloudways account login).
• For SSH key-based access, navigate to Server Management > SSH Keys and make sure the public key has been added and saved properly.
• Cloudways has an IP Whitelist feature under security settings. If it's enabled, the developer's current IP needs to be added. This is easy to miss when someone is working from a new location or a different network.
• Port 22 is standard. If your connection is timing out rather than being refused, the whitelist is almost certainly the issue.

WordPress Admin Is Inaccessible After Migration

You migrated a site using the Cloudways Migrator plugin and now /wp-admin returns a blank page, redirect loop, or 500 error.

Fix — in order:

• Check Application Management > Application Settings and confirm the WordPress site URL matches your actual domain or staging URL. A mismatch here causes redirect loops.
• Disable caching temporarily. Go to Application Management > Varnish and purge the cache, then try again.
• If the blank page persists, enable WordPress debug mode via the application's file manager or SFTP, then check the debug log for specific PHP errors.
• Plugin conflicts are common after migrations. Temporarily rename the plugins folder via SFTP to disable everything, then reactivate plugins one by one.

A clean migration usually takes under 10 minutes. If you're getting errors after that, the problem is almost always a URL mismatch or a plugin that doesn't survive a server environment change gracefully.

Team Member Can't Access the Application

You added a collaborator but they're getting a permissions error or can't see the server.

What's happening: Cloudways has two separate permission layers — Team Member access and Application-level access. Adding someone to the account doesn't automatically give them access to every server or app.

Fix:

• Go to Account > Team Management , find the team member, and review their assigned roles.
• Application-level access is granted separately. Under the specific application, check who has been assigned access.
• For small teams managing 1–5 sites, the simplest approach is assigning the Project Manager role, which covers most day-to-day needs without handing over billing or account settings.

Site Is Slow After Setup

You've launched and the site is live, but it's loading slower than expected.

Before assuming you need a bigger server, check these first:

• Cloudflare CDN is not connected. Cloudways integrates directly with Cloudflare. If you skipped that step, static assets are being served from your server's single location. For a small team with users in multiple regions, this matters.
• Caching isn't active. Cloudways offers Varnish, Redis, and Memcached. If none of them are enabled, every page request hits PHP and the database directly. Enable Breeze (Cloudways' free caching plugin for WordPress) and Varnish at minimum.
• Server size is too small for the actual load. A 1GB RAM server handles light traffic fine, but if you're running WooCommerce with several concurrent users, it will struggle. Scaling up takes two clicks and no downtime on Cloudways — it's not a painful process.
• Unoptimized images. This is a content issue, not a server issue. Run your URL through Google PageSpeed Insights to separate server-side problems from asset problems.

Validation Checks Before You Call the Setup Complete

Before handing a site over to a client or marking a migration done, run through this list:

• ✅ Staging URL loads correctly with no errors
• ✅ Custom domain resolves and shows the site (not the staging URL)
• ✅ HTTPS is active and the padlock shows on all pages
• ✅ No mixed content warnings in the browser console
• ✅ WordPress admin is accessible and functional
• ✅ SFTP or SSH access confirmed for anyone who needs it
• ✅ Automated backups are scheduled and a test backup exists
• ✅ Team members have correct role assignments
• ✅ Caching is enabled and tested (check with a tool like GTmetrix)
• ✅ Email sending is working — Cloudways doesn't include transactional email by default, so you'll need an SMTP integration like SendGrid or Mailgun connected and tested

That last point catches people off guard more than almost anything else. A site can look fully functional and still be silently failing to send password resets, order confirmations, or contact form submissions.

When to Contact Cloudways Support

Cloudways support is available 24/7 via live chat. For small teams without a dedicated sysadmin, this is genuinely useful — don't treat it as a last resort.

Reach out when:

• A server launch has been stuck for more than 15 minutes
• You're seeing server-level errors (5xx) that you can't trace to a plugin or theme
• A billing charge doesn't match what you expected
• You're considering scaling up and want confirmation on what server size fits your actual traffic

Support can't log into your WordPress admin or fix application-level issues that aren't infrastructure-related, but they handle server and platform problems directly and quickly in most cases.

For a full picture of what Cloudways does well and where it has real limits, the Cloudways review covers both honestly. If you're still weighing whether it's the right fit for your stack, the Cloudways vs. alternatives comparison breaks down how it holds up against the other platforms small teams typically consider.

Start Your Cloudways Trial

Did It Work? Run These Checks First

Before you call it done, run a quick binary pass. Each item is a yes or no — no partial credit.

Server and app checks:

• Your app status shows "Running" in the Cloudways dashboard
• The site loads at the temporary Cloudways URL (not just a default server page)
• SSL is active and the padlock shows in the browser
• Your staging branch (if you created one) is separate from production
• At least one team member besides the owner can log in to the platform
• Automated backups are enabled and show a scheduled time

DNS and domain checks:

• Your custom domain resolves to the Cloudways server IP
• Visiting http:// redirects cleanly to https://
• No mixed content warnings appear in the browser console
• Email or login flows on the site aren't broken after the domain switch

If anything is a "no," stop there. A live site with broken SSL or a missing backup schedule isn't ready — it's just exposed. Fix the gap, recheck, then move forward.

Ready to Go Live? Answer These Before You Flip the Switch

The binary checks tell you if things work. These questions tell you if you're ready. They're worth five minutes before you point your real domain at production.

Is your team access set up correctly? Every active team member should have their own login. Shared credentials are a liability — when something breaks at 11pm, you need to know who touched what. Cloudways lets you add team members with scoped permissions, so there's no reason to share the owner account.

Do you have a restore path? Knowing backups are scheduled isn't the same as knowing how to use them. Before going live, walk through the restore flow once — even on staging. It takes ten minutes and means you won't be reading documentation during a real incident.

Is the server size appropriate? A 1GB server might be fine for a simple brochure site. It won't hold up if you're running WooCommerce with active traffic. Cloudways makes vertical scaling straightforward — you can upgrade the server without rebuilding — but it's better to start at a sensible size than to discover limits under pressure.

Have you tested on mobile and in a second browser? Staging environments sometimes mask display issues that only appear when you hit a real CDN or a different browser cache. Take two minutes and check.

Does your team know who owns what? For small teams especially, vague ownership creates gaps. Decide before launch: who monitors uptime alerts, who handles billing, who approves server changes. It doesn't need to be formal — a shared doc or a Slack message is enough. Just make sure it's written down somewhere.

If you can answer yes to all five, you're genuinely ready.

Toolvoro Pro Tips

Pro Tip 1: Use the clone feature before any major change, not just for launches.

Most teams treat cloning as a launch-day tool, but it's more useful as a pre-change safety net. Before you update a plugin, change a PHP version, or install a new theme, clone the app first. The clone takes a few minutes and gives you an exact rollback point without touching your backup schedule. Small teams often skip this because it feels like extra work — until the one time it saves them two hours of recovery.

Pro Tip 2: Set server alerts before you need them, not after.

Cloudways has server monitoring built in, but the alerts don't configure themselves. Go into the monitoring settings and set thresholds for disk usage, PHP memory, and server load. The defaults are fine for a starting point, but adjust them based on your actual traffic patterns after a week or two. An alert at 80% disk usage gives you time to act. Finding out at 100% means something already broke.

Pro Tip 3: Don't overlook the bot protection setting under Cloudflare Enterprise.

If your plan includes Cloudflare Enterprise through Cloudways, the bot protection toggle is off by default. For small teams running lean WordPress or WooCommerce sites, aggressive bot traffic can quietly eat server resources and inflate your bandwidth usage. Enabling bot protection takes about thirty seconds and can meaningfully reduce junk load — especially if your site has any public-facing forms or a login page.

Frequently Asked Questions

How long does it actually take to set up Cloudways for a small team?

For a single site with one or two team members, most people are fully configured in two to three hours — server launch, app install, SSL, domain, backups, and access setup. If you're migrating an existing site using the Cloudways migrator plugin, add another thirty to sixty minutes depending on site size. The platform isn't instant, but it's not complicated either. Most of the time goes to DNS propagation, which is outside Cloudways' control.

Which cloud provider should a small team choose?

DigitalOcean is the most common starting point and for good reason — it's reliable, well-documented, and cost-effective at small scales. Vultr is a close second and sometimes performs slightly better on raw speed tests. AWS and Google Cloud are available but add complexity that most small teams don't need. Start with DigitalOcean unless you have a specific reason to go elsewhere.

Can multiple team members manage the same server?

Yes. The team member feature lets you add users with different permission levels. You can give someone full access or restrict them to specific apps. This matters for small teams where one person handles development and another handles client billing — they don't need to see the same things.

What happens if I need to scale up later?

Scaling a server on Cloudways is a vertical operation — you pick a larger plan for the same server. It triggers a brief restart, typically under a minute. You don't need to rebuild the app, re-configure DNS, or re-install anything. For most small teams, this is the right model: start smaller, scale when you have evidence you need more.

Is Cloudways right for non-technical team members?

The dashboard is more approachable than cPanel or direct server management, but it's not a no-code tool. Someone on your team needs to understand basic hosting concepts — SSL, DNS, PHP versions, file management. If no one on the team has that comfort level, you'll want to invest some time in onboarding before handing over server access.

What if the site goes down after launch?

Check the server status in the dashboard first — Cloudways shows real-time server health. If the server is running but the site is down, check recent application changes and PHP error logs (available under the app's monitoring tab). If you have uptime monitoring connected, you'll already have a timestamp for when things went sideways. That narrows the search significantly.

Does Cloudways handle WordPress updates automatically?

WordPress core and plugin updates are not automatic by default — you manage them manually or through a third-party tool. Cloudways does offer a staging environment so you can test updates before pushing to production, which is worth using before any significant update. Some teams use a tool like ManageWP alongside Cloudways for bulk update management across multiple sites.

Related Reading

If you're still working through whether Cloudways is the right fit or you want to go deeper on specific workflows, these pages cover the adjacent decisions:

The Cloudways review breaks down the platform's strengths and trade-offs for teams who want a full picture before committing.

If you're weighing Cloudways against other managed hosts, the Cloudways vs. alternatives comparison covers the major options side by side.

For teams thinking about automating parts of their hosting workflow, the Cloudways automation strategy guide is worth reading after you've stabilized your setup.

And if you're not fully convinced yet, best Cloudways alternatives gives you a grounded look at what else is worth considering.

Ready to Get Started?

If the checks passed and the readiness questions came back yes, you're in good shape. The setup decisions are behind you.

Still working through the full setup process? The step-by-step walkthrough covers every configuration decision from server launch to going live.

Read the Full Setup Tutorial

Not sure Cloudways is the right call for your team's situation? Take a look at how it compares before you commit.

Compare Cloudways vs. Alternatives