v1.2.15

A service with load-balanced copies no longer sends traffic to a new container before it is healthy during a deploy. The new first container now waits for its health check (its Docker healthcheck, or the readiness probe when the service has one) before it takes requests, and the copies are only replaced after that, so a copy of the previous release keeps answering while the new release starts. If the new container does not become healthy within 120 seconds, it stays out of rotation, the copies keep serving the previous release, nothing else is replaced, and the deploy says so (with the health check set to fail, the service is marked failed). A service without a healthcheck or probe deploys as before, and the log says it has no health gate.

The cleanup of unused Docker images (the nightly sweep and the one after a deploy) now skips removing dangling images on a server while any build or deployment runs on it, for any project. It used to skip only the project being deployed, which could make another project's build on the same server fail at the end.

A service in a compose project can now run 2 to 10 identical containers (Settings > Load balancing, or POST /api/projects/:id/services/:serviceId/replicas). The edge spreads its requests across them (round robin, least connections, or sticky by client IP) and skips a container that fails. The first container keeps its name and published port; each copy gets its own loopback port and the same environment, networks and aliases, so callers that use the service's name reach every copy. Custom config that proxies to the service's published loopback port is balanced too, with no edit. With two or more containers a deploy replaces them one at a time, so the service keeps answering during deploys; Apply environment and port changes roll the same way. A request that already reached a container is never sent to a second one. Refused, with the reason, for host-network services, ports published on every interface, services without a port and (unless you confirm) writable shared volumes. Each extra container uses its own CPU, memory and database connections.

Hosts the edge serves now show as live (the vhost scan failed on containerized edges, so every host read "Not live"), and the panel's own hostname points at the panel dashboard container instead of "Missing".

POST /api/domains accepts an optional targetPort: it creates a routed project-level domain, or sets the port of an existing one of the same project, without replacing the project's whole endpoint list. A live project is re-routed right away; the domain's verification, certificate and custom proxy config are kept. Refused for a service's route, a static-path domain and a redirect.

A service can run on the server's own network (network_mode: host) once the server's operator allows it with sudo synq host-network on. It is off by default, and synq host-network off turns it off again; synq host-network status shows the setting and what the running api uses. It is meant for workloads that can't run any other way, such as a media server with a wide UDP port range or a mail relay that must send from the server's own address, and only for images you trust: such a container can reach every service on the server's loopback (the panel's API, the edge's management port, the mail engine) and every container on the server, the panel's Postgres and Redis included. Synq drops NET_RAW from it and refuses NET_ADMIN, NET_RAW and ALL in its capabilities. Once it is on, anyone who can edit a service can use it. While it is on, compose imports, the services API and synq service sync accept it.

A domain on a host-network service, or a project domain mapped to its port, routes to the port the service listens on.

synq edge on --migrate and synq edge migrate now follow include inside a server block (globs and paths relative to the nginx config directory), so a site whose locations or certificate live in a snippet is carried over instead of skipped.

An nginx site whose / answers by itself (return 403, deny all) while a few paths are proxied is skipped with a warning naming those paths, instead of being imported as a proxy for every path. A locked sub-path under a proxied site is named in the warnings.

A quoted value may now hold braces that pair up, so return 503 '{"error":"x"}'; is accepted.

A service's routes can list more than one hostname for the same port (a.com and b.com on 3000); each gets its own domain row and route. Before, only the first was kept and the rest were dropped without a word.

Adding a hostname that one of the project's services still routes to the project's own domains is refused with the service's name (a deploy leaves it with the service), and a service edit that would drop a hostname holding a saved custom proxy config is refused until that config is cleared.

On a server installed with --edge off, a deploy of a project with custom domains no longer ends "with warnings" under "Some services need attention" or flags the project for a routing retry. The same sentence (edge off, domains activate on synq edge on) is shown as an informational note with the domains that wait.

A job that runs inside a service's container (projectId + serviceId) can now target a project deployed on the server the panel runs on. It answers to that host's "This Server" entry, with the same project and server permissions as any other job there; it was refused with "not deployed to one of your servers".

The services API accepted network_mode: host, stored it, and then deployed the service on the project network anyway. It now refuses it with the reason while host networking isn't allowed. A service that already asks for it fails only its own deploy, with the reason and the way back (set the service's advanced.networkMode to null, or remove network_mode from its compose file), and the rest of the stack deploys.

network_mode or pid pointing at the edge, the panel's api, dashboard, databases, the mail engine or cloudflared, or at a container on the host's own network while host networking is off, is refused instead of reaching the host's network through another container.

A domain can no longer be routed to 127.0.0.1 on the panel's API, dashboard or website port, the edge's management port or the edge's own 80/443, whichever path writes the route.

On an install whose panel already manages itself, the api that synq edge on restarts halfway through rolled the takeover back: it stopped the new edge and restarted the old web server. A takeover still in progress is now left to the command running it, and one that was really interrupted is still rolled back.

Certbot certificates a migrate or takeover kept, issued through the old web server's webroot or nginx plugin, failed every renewal in the edge; they now renew through the edge's own challenge listener, and keep renewing that way.

On a server installed with --edge off, a deploy that publishes a port failed with "Cannot read Synq edge routes"; it now goes ahead, since no edge route can hold a port there.

Synq installs on arm64 (aarch64) Linux servers such as AWS Graviton, as well as on x86_64. The installer fetches the matching Node runtime, and each server pulls the images built for its own CPU.

--edge off installs and runs the panel without Synq's edge, so the web server that already holds ports 80 and 443 keeps them and keeps serving. The panel listens on 127.0.0.1 (reach it over an SSH tunnel), and domains and certificates wait until synq edge on hands the ports to Synq, migrating or taking over, with an automatic rollback if that fails. synq edge restore gives the ports back to the web server Synq replaced.

Adopting running containers now keeps the Docker networks they share with other containers (joined by name, never created or removed), the names other containers call them by (as exact aliases), their extra hosts entries (including host-gateway), ports published on one address such as 127.0.0.1, and their stop grace period, and a redeploy recreates the same wiring. The settings show under a service's networking settings and can be set through the API. Compose files' extra_hosts are now imported instead of being reported as unsupported.

A redeploy waits for the service's stop grace period before starting the new container, so a slow shutdown can no longer leave the old container holding its port.

--version installs work for the three newest releases; older ones were never removed before.

Setting a database's external port (or any published port) to one that a program outside Synq already listens on is refused with the program's name and a free port to use, even when the service hasn't been deployed yet, instead of the first deploy failing to start it.

External access shows a name such as app.synquic.tech instead of the server's IP address when that name points at the server: the server's own connection hostname (Server, Security), else the panel's domain or your apps domain. A name that points elsewhere (a proxy, a stale record) is never used, and the card says which name it chose. Anyone can still look the name up, so the SSH tunnel stays the private option.

Turning on External access for several databases at once gives each its own port (5432, then the next free ones), and the card says why a database didn't get the standard port. A port you type that another service, Synq itself or another program already uses is refused with the holder's name and a free port to use instead ("Use port N"), and nothing changes. If applying a port change fails, the service goes back to how it was. Every writer of published ports now takes the same per-server lock.

Synq is licensed under the Synq License (a license key is required; renaming, rebranding and reselling aren't permitted), shown at synquic.tech/license. Third-party portions keep their own licenses, listed in the NOTICE file that ships with Synq.

An image that brings its own start command (FROM nginx with no CMD, say) now runs as a web app on the port its Dockerfile exposes, instead of failing as if it were a static site.

New apps get a free subdomain on your apps domain with no setup: set one with --apps-domain apps.example.com when installing, with sudo synq apps-domain set apps.example.com, or in Settings, Instance (add a wildcard DNS record *.apps.example.com pointing at the server). Without one, a panel on a domain uses that domain, and a panel on an IP address gives apps <app>.<ip-with-dashes>.sslip.io addresses that work with no DNS at all. HTTPS certificates are requested on the first deploy.

Run 1 to 20 copies of an app on one server with the traffic spread across them, and scale without rebuilding. Turn on autoscaling to add a copy when CPU (or memory) stays above your target for 2 minutes and remove one after 10 quiet minutes, within your minimum and maximum and only when the server has the memory for it. Every change is shown on the app, in the audit log and as an "App autoscaled" notification.

Let a server build for others, then pick "Build on" in a project's settings: the image is built there with the same builders and secrets handling, checked, and handed to the deploy server over Synq's own connections, so heavy builds don't slow production.

FTP and FTPS, Dropbox and Google Drive (with your own Dropbox app or Google OAuth client; Synq walks you through connecting).

On sites running the official WordPress image: update core, plugins and themes (backing up first), change the site's address with a dry run first, reset an admin password, maintenance and debug modes, cache flush, and PHP limits such as upload size and memory.

A new template with a password-protected editor, the runtimes you pick (Node, Bun, Python, Go), an optional repository to clone, and one click to expose a dev server's port on its own domain.

On a server installed without one (http://<IP>:3001), sudo synq panel-domain panel.example.com --email you@example.com moves the panel to https://panel.example.com: it checks DNS, issues the Let's Encrypt certificate while the panel keeps its current address, then switches, and goes back to the old address if the new one doesn't come up. The same command moves the panel from one domain to another.

A database's connection card has an External access switch: Synq publishes its port on the server (pick one or let Synq choose) and shows the external connection URL and CLI command. Your cloud firewall (an AWS security group, say) still has to allow the port. For testing without opening a port, the card also gives an SSH tunnel command.

PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Valkey, KeyDB, Dragonfly, ClickHouse and RabbitMQ. Synq runs the engine's own command inside the container, checks the new password logs in (and, where it can, that the old one no longer does), puts the old one back if anything fails, then updates the service's settings and every linked app's connection variables and offers to redeploy them. Owners and admins only; the password never appears on a command line or in logs.

Pgweb, phpMyAdmin, mongo-express or Redis Commander, wired to the database with its credentials and reachable through an SSH tunnel only. RabbitMQ's management UI and ClickHouse Play are offered the same way.

The logs page has a History tab next to Live: pick a time range (15 minutes to 7 days, or custom), filter by stdout or stderr, level and text, one service at a time. New containers keep more log history (5 files of 20 MB each).

On each project and each service, in Markdown, from the Overview tab, the API, MCP or synq project notes / synq service notes.

Write $(PROJECT_NAME), $(SERVICE_NAME), $(PRIMARY_DOMAIN), $(PUBLIC_URL), $(GIT_SHA), $(GIT_SHORT_SHA), $(GIT_BRANCH), $(DEPLOYMENT_ID) or $(PROJECT_ID) inside an environment variable and Synq fills it in at deploy time. Running apps also get them as SYNQ_* variables unless you set the same names yourself.

Connect a Cloudflare API token to a server, pick or create a tunnel, and Synq runs cloudflared there. Route any domain through the tunnel from its menu: Synq adds the tunnel rule and the DNS record (asking before it replaces an existing record), and Cloudflare serves its certificate. Useful for servers without a public IP or open ports.

From its page (admins only, with an extra confirmation for the server Synq itself runs on).

Per service: all GPUs or a number of them, checked before the deploy starts.

And a storage class for S3 backup destinations (Standard, Infrequent Access, Intelligent-Tiering, Glacier Instant Retrieval and more).

.Tar.bz2, .tar.xz and .tar.zst, next to .zip, .tar and .tar.gz.

Extra system packages for Nixpacks, Railpack and Buildpacks builds from the project's builder settings.

OpenClaw and Hermes Agent.

The command journal is ~/.synq/bin/synq-run, and the old copy is removed the first time Synq runs a command on that server after the update.

Email p@synquic.com to get one. The installer passes it to the panel, which checks in with synquic.tech every hour and gets a signed lease back; a fake server cannot answer for synquic.tech.

Synquic sees each installed panel (installation ID, license key, server IP, domain, version, last seen) and can block it; revoking a license key blocks all its panels.

At its next check-in: it shows "This Synq panel is not active" with its installation ID and how to reach us. A panel that cannot check in for 72 hours locks the same way. Apps already deployed keep running either way.

The command-line tool that the install command downloads is now minified like the server images (no comments, no source paths, no source maps; its backend bundle went from about 450,000 readable lines to a compact minified file), and every download is checked at build time: a build fails if it would ship source files, source maps, readable bundles or the edge's scripts as text.

Synq's routing, rules and analytics scripts in the edge image are LuaJIT bytecode, checked to load in the edge itself; the text copy that used to travel inside the API is gone.

It no longer contains the Synq backend, dashboard or install tools, so it is much smaller (about 125 MB instead of 215 MB on a Mac) and needs no install key. Sign in to your panel inside it as usual. Running Synq on the computer itself and installing a server from the app are removed; servers install with the one-line command and an install key, as before.

A server without Docker gets a clear message to install it.

On first launch it now offers "Connect to your Synq panel" (prefilled with https://app.synquic.tech): sign in with your usual login and two-step code and the app shows your real servers and projects, and stays signed in. Running Synq on the computer itself and installing a new Synq on a server over SSH are still there as other choices; the SSH choice now says it installs a new, separate Synq and warns when that server already runs one.

It has no access to the computer, other websites open in your browser, and camera, microphone, device and clipboard read requests are refused. The app's local bridge only answers its own pages.

A desktop app for Apple Silicon and Intel Macs (DMG) and for Windows (a portable zip: unzip and run Synq.exe). Download it from synquic.tech with an install key: the page asks for the key once and hands out a download link that works for 10 minutes, so the key never ends up in a URL. The app checks synquic.tech for updates with the same key, which it stores encrypted on your computer. Like the server images, the app ships no source code.

With an install key from your Synquic admin: curl -sSL https://synquic.tech/install.sh | sh -s -- --key <KEY> (add --domain panel.example.com --email you@example.com for HTTPS). It sets up Docker, checks every download, and never prints or stores the key outside Docker's own login. Running it again upgrades. The images come from a private, read-only registry on synquic.tech; a request without a valid key gets nothing.

Package downloads (npm, pnpm, yarn, bun, pip, uv, poetry, bundler, composer, go, cargo, maven, gradle) and the Next.js build cache are kept between builds of the same project, and for common Node and Python projects a code-only change reuses the installed dependencies entirely.

Is now a one-click template (WordPress 7.1 with MySQL 8.4 and uploads up to 128 MB).

Environment variables used while building (including secrets such as DATABASE_URL) used to be written into the generated Dockerfile, so they were readable in the image history and in a copy of that file inside the image. They are now passed to the build as a BuildKit secret that is never stored in the image. Servers without BuildKit keep the old behaviour and the build log says how to fix it (install docker-buildx).

The API image is a single minified bundle with its data files: no TypeScript sources, no source maps, and 556 MB instead of 2.9 GB. The dashboard ships no source maps either.

A NestJS app crash-looped with "Cannot find module '/workspace/dist/main'" because Synq ran npm run start, which is the nest start dev server: it recompiles on every boot. Synq now prefers start:prod (or start:production) and never picks a start script that runs a dev server (nest start, nodemon, next dev, vite, ng serve and others). Without a production script it runs the framework's own production command, for example node dist/main.js for NestJS.

When a project's saved start command is npm run start and that script is a dev server, the build uses the production command instead and says so in the build log. Rollbacks to those releases start the same way. A start command you typed is never changed.

49 Sample apps, one per stack, now build, start and answer HTTP. Fixes found along the way:

Django reads its project name from manage.py; collectstatic no longer fails a stock project.

When a check finds that a domain's DNS has no record or points somewhere else, one Issue opens on the Monitoring page with what DNS returned, your server's IP and the exact record to add. It notifies once, updates on the routine checks and closes itself when HTTPS works.

When a one-click app, a Compose app's first deploy, a database's public access or a Ports row left without a host port wants a port another app already uses, Synq picks the next free one and tells you which. A port you typed yourself is still refused if taken, with an Auto-assign button.

Even without a build command. An Express app with only a start command crashed with "Cannot find module"; the install step now always runs for server apps.

From the "Is that the right port?" prompt works, and errors show the real reason.

Everywhere (<name>.synquic.tech), including Services cards, routing and the deploy wizard. No hosted-cloud domain appears any more.

Project variables and each service's variables are listed with masked secrets, reveal (needs edit permission and is audited), copy, inline editing and "Edit as .env", with Save or Save and apply.

, A "What's new in 1.2" page and a complete list of the one-click apps.

On synquic.tech (/docs, /changelog, /download). Every docs and help link in the panel, the CLI and error messages opens there.

GitLab, Bitbucket, Gitea, Forgejo or your own server, over HTTPS or SSH, with an access token or a deploy key Synq generates. Push-to-deploy webhooks for each of them, with signature checks and a delivery log.

Deploy a .zip, .tar or .tar.gz of your app.

Auto, Dockerfile (custom path and context), Nixpacks, Railpack and Buildpacks. Existing projects can switch to their repo's Dockerfile in one click.

Per app: always, unless-stopped, on-failure or never.

In the catalog (from 38), including Nextcloud, Plausible, Matomo, Chatwoot, Mattermost, WAHA, Open WebUI with Ollama, Flowise, Keycloak, authentik, Cal.com, BookStack, Firefly III, LibreChat, Infisical, Jenkins, SonarQube, pgAdmin and many more. See the full list in the docs.

Publish TCP/UDP ports on the server, public or localhost, with clash and reserved-port checks. Public access switch for databases.

Write a config file into a container from the panel (stored encrypted, mounted read-only).

Dedicated cores, "reserve exclusively", CPU priority and reserved memory per project or service.

Create, mount, detach and delete Docker volumes; back them up now or on a schedule, restore and download.

Per server, with a review step and protections for anything Synq, your projects or rollback still need. Optional schedule.

Scheduled backups of Synq's own database and settings.

Is editable in the Certificates tab.

Ntfy, Gotify, Pushover, Mattermost and Matrix channels.

Per domain for admins, validated and rolled back automatically when the edge rejects it.

Page with a valid certificate for domains whose app isn't live, instead of a browser certificate warning.

In the sidebar: every domain across your projects in one table, with its internal target (https://host -> http://service:port), a live DNS check against the record you were told to create, certificate issuer and expiry countdown, and HTTPS state. Filters, search and "Renew N due" in bulk.

Let's Encrypt HTTP-01 is the default and only needs the domain pointed at the server. Wildcards use a connected DNS provider. Each certificate shows its last error and the renewal schedule.

Route, then DNS (checked live, warns about stray AAAA or extra A records), then HTTPS with the live certbot log.

Are shown read-only with instructions to change them.

At Monitoring: CPU, memory and disk dials with alert bands, headline numbers (req/s, active requests, bandwidth in/out, error rate, p95) with sparklines and change vs the previous window, an incident timeline, stacked requests by status, latency p50/p95/p99, load and network charts, a sortable per-app table, top paths, a status donut, busiest domains and the world map.

Overview, Source & Triggers, Deployments, Environment, Domains & Routes, Redirects, Security, Resources, Maintenance, Storage, Backup, Logs, Monitoring, Advanced.

, Templates and Domains in the main sidebar; settings gain Security & 2FA, Users & team, Cloudflare Tunnel, Certificates and Storage links.

New Project has tabs for a Git repo or URL, a folder, a prebuilt Docker image, a pasted Dockerfile, a pasted docker-compose.yml, and one-click apps.

Repos with a Dockerfile build from it, even when a simple compose wrapper sits next to it; other repos get framework detection (Vite and other static sites deploy as static files).

PostgreSQL, MySQL and MariaDB (with Adminer), Redis, Valkey, Dragonfly, Memcached, MongoDB and RabbitMQ.

(app.<your-domain>), automatic HTTPS with Let's Encrypt, password protection (basic auth) and path/regex redirects.

Live active requests, requests per second, bandwidth in/out, p50/p95/p99 latency and status classes, per app and server.

CPU, memory, disk, load and network history with threshold alerts, and per-app disk usage.

Deploy, rebuild, restart, stop/start, terminal, logs and open-app on every project page, with a live CPU/memory/network strip; domain rows show their internal target (https://host -> http://service:port).

(TOTP and backup codes); synq reset-admin-password also clears it for recovery.

MCP tools cover servers, backups, route rules and traffic.

Scheduled jobs can run inside an app's container.

Per app and service: capabilities add/drop, sysctls, extra groups, init process (tini), command, zero-downtime on/off, and an optional env file written into the build.

Serve a 503 maintenance page (custom message or HTML) for a project's domains without redeploying.

Build your own one-click apps from a form, a compose file or JSON, with live validation, import/export, "Save as template" from a project, and an in-app guide.