Bring your own server
Run your automation on hardware you own, and let SpliceRun operate the software on it. You keep the server, the provider relationship and the primary copy of your data. We handle installation, keeping the application patched, backups and monitoring.
We keep the app patched - n8n and everything we installed alongside it. We do not patch the operating system on a server you own. That one is yours, and Keeping the server itself patched below explains exactly what to do about it - it is two commands.
What you need before you start
| Minimum | Notes | |
|---|---|---|
| CPU | 1 vCPU | 2 or more if you run many workflows at once |
| Memory | 1 GB | 2 GB+ is more comfortable for heavier use |
| Free disk | 10 GB | Covers the app, its database, logs and backup staging |
| Operating system | Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, or Debian 12 | These are what our setup is tested against |
| Architecture | x86_64 or arm64 | |
| Network | A public IP address, with ports 22, 80 and 443 reachable | 80 and 443 are how your workflows and webhooks are reached |
| Docker | Not required | We install and manage it as part of setup |
| Ports 80 and 443 | Must be free | If another web server is already using them, setup cannot continue |
Any provider works. There is nothing provider-specific in what we do - we only need a reachable server running a supported operating system.
You also need a domain
You need a domain or subdomain you control - for example automation.yourcompany.com - with its DNS A record pointing at your server's IP address.
A certificate is requested and renewed automatically once setup begins, so there is nothing else for you to do about HTTPS. But the DNS record has to be in place first, because the certificate cannot be issued otherwise.
Setting it up
1. Start the setup in your dashboard
Choose Bring your own server. We generate an SSH key pair specifically for your instance and show you the public half.
2. Add our key to your server
Your dashboard gives you a ready-made command. Run it on your server as the user we will connect as:
mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '<the key shown in your dashboard>' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
The key can be viewed again at any time from the instance page - you do not need to save it now.
The user you give us must be root, or a user with passwordless sudo. We need that to
install Docker and to bind ports 80 and 443.
3. Tell us where the server is
Enter the server's address, the SSH port, the user, and the domain you pointed at it.
4. Run the check
Press Test my server. We connect and check:
- The SSH key works
- The operating system is supported
- There is enough CPU, memory and disk
- The user can install software
- Ports 80 and 443 are free
- Your domain points at this server
Each result tells you what to fix if it fails. Nothing is installed and nothing is charged at this stage - run it as many times as you like.
5. Confirm and let setup run
Once payment is confirmed, setup begins. We install Docker if it is not already there, set up the application, its database and a web server, request your certificate, and run a health check.
You can watch the whole thing on the instance page - every step is logged in plain language as it happens.
After setup
Your instance page shows what we see: whether the app is running, how much CPU and memory it is using, recent logs, and a record of every action we have taken on your server.
From there you can back up on demand, restore any snapshot, check for updates, and revoke our access.
What stays yours
The server is yours, so its operating system, disk, firewall and your relationship with your provider stay your responsibility. We look after the software we installed. The full boundary is in What we manage.
Keeping the server itself patched
This is the one job on this plan that is genuinely yours, so it is worth being precise about.
What we patch: the app, in your maintenance window - see Updates and maintenance windows.
What we do not patch: the operating system underneath it. Ubuntu and Debian both ship security fixes for the kernel, OpenSSL, systemd and everything else on the machine, and nothing we run installs those for you.
Turn on automatic security updates - two commands
On Ubuntu 22.04, Ubuntu 24.04 or Debian 12:
sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
Answer Yes. That is the whole job. Your server will install security updates on its own, which is exactly what we do on our own machines.
To check it is working:
sudo unattended-upgrades --dry-run --debug | tail -20
The part people miss: reboots
Some updates - kernel and core library fixes especially - only take effect after a reboot. A server can be fully patched and still running the old, vulnerable kernel.
To see whether yours is waiting on one:
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required || echo "no reboot needed"
Rebooting takes your instance offline for a minute or two while the machine comes back. Pick a quiet time, and do it deliberately - this is the reason we do not do it for you. Restarting someone else's server is not a decision we are willing to make on your behalf, because we cannot know what else that machine is doing, and if it does not come back up we have no way to reach it.
Why the line is drawn here
| Why it is good for you | What it costs you | |
|---|---|---|
| You own the OS | Nothing we run can break software we did not install. Your machine can do other jobs alongside ours. No one else can reboot your server | You have to turn on unattended security updates yourself, and reboot occasionally |
| We owned it instead | One less thing to think about | We would be applying changes and reboots to a machine we do not control, cannot see the console of, and cannot recover if it fails to come back |
If you would rather not think about the operating system at all, that is exactly what Shared and Dedicated are - on those the server is ours, and we patch it daily without asking. See Choosing a hosting option.
Removing our access
You can remove our SSH key at any time from the instance page. Your instance keeps running - removing the key only stops us managing it, so updates, backups and monitoring stop with it.
When you cancel, we remove the key automatically. See Data and access.
Common problems
"Could not connect over SSH." The key is not in authorized_keys for the user you told
us, the SSH port is different from what you entered, or a firewall is blocking us. Check the
port first - it is the most common cause.
"Ports 80 or 443 are in use." Something else is already serving web traffic - usually nginx or Apache from a previous setup. Stop it, then run the check again.
"Your domain does not point at this server." The DNS A record is missing, or still propagating. This one is only a warning, not a blocker - but the certificate cannot be issued until it resolves, so your instance will not be reachable over HTTPS until then.
"The user needs root or passwordless sudo." We cannot install Docker or bind port 443 without it.
"Your server is below the minimum spec." The check reports what it found. Resize the server at your provider and run the check again.