Connect your own server
Add one of your own machines over SSH and let Synq install everything it needs to run your apps.
Synq can run your apps on a machine you already own — a cheap VPS, a spare box, a rented cloud server. You hand Synq the address and a way to log in over SSH (the standard secure way to control a remote computer from a terminal), and it does the rest: it connects, checks what's already installed, and sets up the missing pieces for you.
Think of it like hiring a mover who also assembles the furniture. You give them the keys to the new place; they show up, bring the tools, and get the room ready. You don't have to install anything by hand.
What you need first
- A running Synq install (see Installation). Connecting your own servers is a self-hosted feature, and every Synq install is self-hosted.
- A server you can reach over SSH — Ubuntu, Debian, or a similar Linux works well.
- A way to log in: an SSH key, a password, or your machine's SSH agent.
- That's it. You do not need to pre-install Docker or anything else — Synq installs what's missing.
Steps
Open the Servers page and start adding
In the dashboard, open the Servers page and press Add Server. (If this is your first server, the empty page has an Add Your First Server button that does the same thing.)
Fill in the SSH connection form
This is the "who am I connecting to, and how" screen. The fields:
- Server Name — an optional label like
ProductionorStaging, just so you can tell servers apart. Leave it blank and Synq uses the IP address. - Server IP Address — the address of your machine, e.g.
203.0.113.10. - Port — the SSH port. Almost always
22(the default). - Username — the user to log in as. Usually
root. - Authentication — pick one:
- Password — type the server's password.
- SSH Key — give the path to your private key file (like
~/.ssh/id_ed25519) and, if the key has one, a passphrase. - Agent — use the SSH agent already running on the machine that hosts Synq (like VSCode does). No password or key needed here, but that host must already be allowed to log in to the server.
There's an Advanced section too, for a Jump Host (a bastion server you must hop through first) and Extra SSH Arguments — you can ignore both unless you know you need them.
Test before you save
Press Test Connection first. Synq tries to log in and reports back without saving anything. A green Connected means your details are right. Fix any red message before moving on — it saves you guessing later.
When the test passes, press Save & Continue to Setup.
Choose how to set the server up
Once the server is saved, Synq offers two ways to install what's needed:
- Automatic Setup — one click. Synq checks the server and installs everything missing for you.
- Step-by-Step Setup — you review each component and choose what to install, seeing detailed status first.
If you're new, pick Automatic Setup.
Watch the core components install
Synq now connects over SSH and installs what your apps need to run. You'll see each piece light up as it finishes, with a live log you can expand.
Setup installs the core components first — the ones the server can't run apps without:
- Docker — the container runtime that actually runs your apps.
- Git — used to pull your source code.
The routing and certificate tools aren't installed now. Synq adds them automatically later, the first time a deployment actually needs them — you never install them by hand:
- OpenResty — the reverse proxy that routes web traffic to the right app. Added the first time an app needs a public web address.
- Certbot — provisions free HTTPS certificates from Let's Encrypt, so your sites get SSL. Added the first time an app needs HTTPS.
- rsync — fast file transfer, added when a build is made elsewhere and copied to the server.
Once any of these is installed, it shows up on the server's Components tab (below), where you can re-check, reinstall, or remove it. When setup finishes, you land on the server's own page.
What's on the server page
Each server gets its own page, split into tabs. From here you can see how it's doing and manage it.
- Overview — live stats for the machine: CPU, memory, disk, uptime, and load, plus a quick list of which components are healthy.
- Components — the health list for this server. Re-check re-runs the checks, Install Missing installs any core components the server still needs, and each installed component can be reinstalled or removed.
- Security — request rate limiting (see below) and a port-exposure scan that lists which ports are listening and flags any bound to a public interface vs loopback-only.
- Terminal — a live SSH shell right in the browser, so you can poke around the server without leaving Synq. Up to 3 shells at once.
The header also has Edit (change the connection details) and, in the "…" menu, Remove Server (which clears the stored SSH credentials and settings).
Rate limiting (Security tab)
Rate limiting caps how many requests a single visitor can make per second, so one noisy client (or a bad bot) can't swamp your apps. It's applied at the OpenResty level for the whole server.
Set Requests / second to turn it on. Synq picks a sensible burst allowance automatically
(a small buffer for short spikes), or you can set your own under Advanced. You can also add
Whitelisted IPs — addresses or CIDR ranges (like 10.0.0.0/8) that skip the limit entirely.
Loopback (127.0.0.1, ::1) is always whitelisted. Setting requests per second back to 0 removes
the limit.
CLI
Everything above works from the CLI. You must be logged in (synq login) and on a self-hosted
Synq.
# Add a server (this validates the connection, then saves it)
synq server add \
--name production \
--host 203.0.113.10 \
--user root \
--auth-method key \
--key-path ~/.ssh/id_ed25519
# List your servers to grab the id you'll need below
synq server list
# See what's installed on that server
synq server check <server-id>
# Install the missing pieces, streaming the logs live
synq server install <server-id> --component docker git openresty --followYou can also test a connection without saving it, watch live stats, or manage rate limiting:
# Try credentials without creating a server entry
synq server test-connection --host 203.0.113.10 --user root --auth-method key --key-path ~/.ssh/id_ed25519
# Stream live CPU / memory / disk stats (Ctrl-C to stop)
synq server monitor <server-id>
# Set a rate limit of 50 req/s (use --rps 0 to remove it)
synq server rate-limit <server-id> --rps 50 --burst 20The installable components are docker, git, openresty, certbot, and rsync.
Troubleshooting
Can't reach the server
Synq couldn't open an SSH connection. Check that the machine is powered on, that its SSH service
is accepting connections on the port you entered (usually 22), and — if it's behind a firewall or
NAT — that the host is reachable from where Synq is running. The server page shows this as a
Can't reach banner with the exact host and port.
SSH credentials rejected
Synq reached the server but the login was refused. The key or password you saved doesn't match
what the server allows in its ~/.ssh/authorized_keys. Open Edit on the server and fix the
credentials, then run a health check again. If you chose Agent, make sure the host running Synq
actually has a working key loaded for that server.
A component failed to install
Open the Components tab and expand the install log — the last red lines say why. Common causes are no internet access on the server or a package manager that's busy or locked. Fix it on the server, then press Re-check and Install Missing to retry just the parts that failed.
Rate limit says it can't read the config
The Security tab reads its settings from OpenResty. If OpenResty isn't installed (or isn't reachable) you'll see a "couldn't read" message. Install OpenResty from the Components tab first, then return to Security.
Related guides
WordPress tools
Manage a WordPress site from its service: versions, plugin, theme and core updates, maintenance and debug mode, search-replace for a new URL, an admin password reset and PHP limits, all through WP-CLI.
The edge
Synq's built-in reverse proxy. How your apps get a public address and HTTPS, how you protect a route, where your traffic numbers come from, and how to take over a proxy that's already running on a server.