Getting Started

Installation

Install Synq on your own Linux server with one command and your license key, with or without a domain. Set up the panel's domain and your apps' domains, check the install, update it and remove it.

Synq runs on a Linux server you control. You install it with one command and your license key: the installer downloads Synq, installs Docker if the server doesn't have it, and starts the panel, its API and database, and the edge that serves your apps on ports 80 and 443 with free Let's Encrypt certificates. There is nothing to build and no source code to download.

curl -sSL https://synquic.tech/install.sh | sh -s -- --key <KEY>

Before you start

You need:

  • A Linux server on x86_64 (amd64) or arm64 (aarch64): Ubuntu 22.04 or newer, or Debian 12 or newer, with 2 GB of RAM or more (4 GB recommended) and about 10 GB of free disk.
  • Ports 80 and 443 open to the internet. Without a domain, open port 3001 too.
  • Outbound HTTPS to synquic.tech, for downloads and the panel's license check-ins.
  • A shell on the server as root, or as a user that can use sudo.
  • A license key. Email p@synquic.com to get a license key.
  • Optional: a domain for the panel, such as panel.example.com, with a DNS A record pointing at the server's public IP. You can also add it later.

Install

Log in to the server and run:

curl -sSL https://synquic.tech/install.sh | sh -s -- --key <KEY>

The installer asks for the admin account's email and password (8 characters or more), then serves the panel on http://<server IP>:3001. Open port 3001 in the server's firewall (on AWS, in its security group) and sign in.

Without a domain the panel is served over plain HTTP, so your password travels unencrypted. It's fine for a first look; give the panel a domain before you use it for anything real.

First create a DNS A record for the panel's host (for example panel.example.com) pointing at the server's public IP. Then run the installer with --domain and --email:

curl -sSL https://synquic.tech/install.sh | sh -s -- --key <KEY> \
  --domain panel.example.com --email you@example.com

The panel comes up on https://panel.example.com with a Let's Encrypt certificate. --email is where Let's Encrypt sends certificate notices, and the admin account's email unless you pass --admin-email.

Every option, what the installer changes on the server, and how licensing works are on Install on a new server.

Domains

A Synq install uses domains in two places: the address of the panel itself, and the addresses of the apps you deploy. Both are yours: nothing points at Synquic's DNS, and your apps never get Synquic's domain.

The panel's domain at install

With --domain panel.example.com --email you@example.com, the installer:

  1. checks that panel.example.com resolves to this server and says so if it doesn't yet;
  2. puts Synq's edge in front of the panel on ports 80 and 443, and keeps the panel's own ports (3001 and 4000) off the public network;
  3. requests the Let's Encrypt certificate. If DNS isn't ready, Synq keeps retrying in the background and the certificate is issued as soon as the record resolves.

Move the panel to a domain later

Installed without a domain, or want the panel on another host? Point the new host's DNS A record at the server, then run this on the server:

sudo synq panel-domain panel.example.com --email you@example.com

It does the same as --domain does on a first install, in an order that keeps the panel reachable:

  1. Checks DNS. If panel.example.com doesn't point at this server yet, it stops and tells you which record to create. Nothing is changed.
  2. Gets the certificate first. It adds the host to Synq's edge and requests the Let's Encrypt certificate while the panel keeps working on its current address. If the certificate can't be issued, it removes the host again and stops: the panel stays where it was.
  3. Moves the panel. Synq restarts on https://panel.example.com (your deployed apps keep running), with the panel's own ports back on the loopback interface. If the new address doesn't answer over HTTPS with a trusted certificate, Synq goes back to the previous address by itself.

Running it again for the host the panel is already on changes nothing. sudo synq panel-domain with no host shows the panel's current address. --email can be left out once the install has a Let's Encrypt contact. If a proxy such as Cloudflare sits in front of the server, so the host doesn't resolve to the server's own IP, add --skip-dns-check.

After the move, sign in at the new address (sessions belong to an address, so everyone signs in again), close port 3001 if you opened it, and update anything that used the old address: CLI contexts, AI agents connected over MCP, Git webhooks and bookmarks. More in Domains for the panel and your apps.

Your apps' domains

  • Custom domains. Give any app your own domain: point its DNS record at the server, add it to the app, and Synq verifies it and issues the certificate. See Custom domains.
  • An apps domain. With a wildcard record *.apps.example.com pointing at the server, apps can get free subdomains such as shop.apps.example.com without a DNS change each time. Set the apps domain at install with --apps-domain apps.example.com, or later in the panel's Settings (Instance, Apps domain) or with sudo synq apps-domain set apps.example.com. See Free subdomains.
  • Without a domain. On an install that only has an IP address, apps get addresses such as shop.203-0-113-10.sslip.io by default, which work without any DNS setup.

License terms

Your license key lets you run Synq on your own servers for your own projects and your team's. Renaming, rebranding or reselling the panel isn't permitted: the Synq name and logo are built in, and only the domains are yours to choose. The full terms are the Synq License.

Check it's working

Open the panel address the installer printed and sign in with the email and password you chose. Synq runs as root, so manage it on the server with sudo:

sudo synq status    # is it running, its ports, and the API's health
sudo synq doctor    # checks the database and services, and can repair them (--fix)

Forgot the admin password, or lost the phone with your two-factor codes? Run sudo synq reset-admin-password on the server: it resets the owner's password, turns two-factor authentication off for that account and signs it out everywhere. See Two-factor authentication.

After installing

A few things worth doing once the panel is up:

  1. Give the panel a domain if it doesn't have one yet (above).
  2. Check the certificate contact email. Open Domains, Certificates. If the Contact email reads Not set, save your address there (details).
  3. Turn on panel backups to a destination off the server (Back up and restore the panel).
  4. Turn on two-factor authentication for your account under Settings, Security & 2FA.
  5. Invite your team under Settings, Users & team (Teams and members).

Prefer a window of its own? The free desktop app for Mac and Windows opens your panel.

Update

Run the installer again with your key. It upgrades Synq to the newest release and keeps the database, settings, certificates and the panel's address; your apps keep running. See Updating Synq.

curl -sSL https://synquic.tech/install.sh | sh -s -- --key <KEY>

Host control (hardening)

The panel can operate the server it runs on: free ports 80 and 443 from an existing proxy, read host config, scan listening ports, open a host shell. That channel is an SSH key to the host that Synq generates and authorizes for root, reached over the internal host.docker.internal bridge, never the public IP.

It can be present in name only

Generating a key isn't the same as a working channel. Two things on the host decide it: an sshd listening where containers can reach it, and a firewall that allows container-to-host traffic. synq doctor checks the channel; the repair and the failure it produces are in Troubleshooting → Host control channel.

To withhold it on a server that only manages remote servers, run sudo synq up --no-host-control once after installing; upgrades keep the choice. With it set, no host key is generated or mounted, host operations refuse with a clear error, and the server stops being listed as a deploy target ("This Server" disappears). It is a command on the server on purpose: a toggle in the dashboard would be reachable by the very thing it defends against.

Your serverRecommendation
Deploys apps to itself (the common single-server install)Leave host control on. It's needed for the :80/:443 takeover, host port scans, and the host terminal.
Only manages remote servers--no-host-control. It gains nothing here, and removes an easy path to host root.

This is defense in depth, not isolation

The API also mounts the host's Docker socket, because building and running your apps requires it. A mounted socket is host-root-equivalent for anyone who can reach it, the same trade every self-hosted deploy platform makes. Treat panel access as host access.

Stopping and removing Synq

sudo synq stop halts Synq but keeps everything: the database, issued certificates and edge config all survive, and sudo synq up starts it again where it left off. To remove it:

sudo synq uninstall                 # asks first; removes the stack, its data, its images and /root/.synq
sudo synq uninstall --keep-data     # remove the running stack only, keep the database and certificates
sudo synq uninstall --keep-images   # don't delete the Synq container images
sudo synq uninstall --yes           # skip the confirmation (scripts)

Two things it deliberately leaves alone, because a server is often shared:

  • Your deployed apps keep running. Removing the panel doesn't stop the containers it created; docker ps still shows them. Delete the projects first if you want those gone too.
  • Nothing is pruned. Only Synq's own images (by exact tag) and the stack's volumes are removed; your other images, volumes and containers are untouched.

If Synq took over ports 80/443

When Synq migrated an existing proxy during install, uninstalling frees those ports but can't always restart what was there before. Re-enable your proxy yourself (sudo systemctl enable --now nginx, or caddy / apache2). Its config was never modified.

Next steps

On this page