What we need from a server, and exactly how to get there on each major provider. Two minutes of setup up front saves a failed connection attempt later. See the docs for how connecting itself works, or contact us if your provider isn't listed here.
Any box that's all four of these works:
root over SSH. Not a sudo-capable user — literally root. We use the password once, to install our own SSH key, then never store it.A provider's default image either already satisfies all four (DigitalOcean, Hetzner, Vultr, Linode, OVHcloud) or needs one or two quick changes first (AWS, Google Cloud, Azure, Oracle Cloud) — find yours below.
Create an Ubuntu droplet/server/instance the normal way (22.04 or 24.04). Root SSH is already enabled by default on all four — no changes needed. Just connect it straight from My Servers.
The one thing worth checking: if you've turned on a Cloud Firewall (off by default on all four), make sure it allows inbound 80 and 443 from anywhere — SSH (22) is usually already allowed.
Launch an Ubuntu AMI (22.04 or 24.04) — not Amazon Linux. AWS's own Ubuntu AMIs ship with root login disabled and a default user (ubuntu) instead, so two things need changing before you connect:
SSH in as the default user first, then run:
sudo -i
mkdir -p /root/.ssh
cp /home/ubuntu/.ssh/authorized_keys /root/.ssh/authorized_keys
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
systemctl restart sshThen confirm ssh root@your-server-ip logs in before moving on.
In your EC2 instance's Security Group, add two inbound rules: HTTP (80) and HTTPS (443), source 0.0.0.0/0. SSH (22) is usually already open by default.
Create an Ubuntu VM instance (22.04 or 24.04). Compute Engine provisions your own named user via SSH keys, never root directly, so:
SSH in via the Cloud Console or gcloud compute ssh first, then run the same steps as AWS above (swap ubuntu for whatever your own GCP username is — check with whoami).
Compute Engine's default VPC firewall blocks inbound traffic beyond SSH. Create firewall rules (or edit the default ones) allowing tcp:80 and tcp:443 from 0.0.0.0/0, and make sure your instance has the matching network tags if your rules are tag-scoped.
Create an Ubuntu VM (22.04 or 24.04). Azure's own images use the admin username you pick at creation (often azureuser), never root, so:
SSH in as your admin user first, then run the same steps as AWS above (swap ubuntu for your own admin username).
Azure's default Network Security Group (NSG) denies all inbound traffic beyond SSH. Add inbound security rules allowing 80 and 443 from Any source.
Don't use the Always Free Ampere (ARM) shape — our Odoo images are built for standard x86-64 servers and won't run on ARM. Pick an x86 shape instead (e.g. VM.Standard.E*), not VM.Standard.A1.Flex.
Use an Ubuntu image, not Oracle Linux. The default user is ubuntu — enable root SSH with the same steps as AWS above. For networking, add ingress rules for 80 and 443 on your instance's Security List (or Network Security Group, if you're using one).
Root SSH is already enabled by default on an Ubuntu VPS. Just connect it straight from My Servers.
Root SSH is already enabled by default on an Ubuntu VPS. Just connect it straight from My Servers.
Connection times out. Almost always a firewall — double-check port 22 is actually open to your own IP (or everywhere), not just in your provider's own rules but any OS-level firewall (ufw, iptables) running on the box itself.
"Permission denied" connecting as root. Root login is still disabled — re-check the PermitRootLogin yes step above and that you restarted ssh (not just edited the config).
Everything connects, but your site never gets HTTPS. Port 443 isn't actually reachable — automatic certificates need a real, successful connection on 443 from the public internet, not just 80.
Still stuck? Contact us with your provider name and we'll help directly.