# The deploy wizard URL: https://synquic.tech/docs/dashboard/deploy-wizard.md The screen where you review the detected build, choose the server, set a domain, pick a builder, and watch the app go live. The deploy wizard is the screen you land on after picking a source on the [New Project](/docs/dashboard/library) page: a GitHub repository, a Git URL import, an uploaded folder or archive, or a starter template. It answers three questions and then does the work: **does the detected build look right?**, **where should it run?**, and **is it live yet?** The wizard lives at `/deploy/`. When you press **Deploy** it hands off to the live build screen at `/build/`, which streams the logs until your app is online. The **Docker image**, **Dockerfile** and **Compose** tabs deploy directly from their own forms, and one-click apps have their own install wizard (with **Advanced deployment options** leading here). See [Deploy a Docker image](/docs/guides/deploy-docker-image), [Paste a Dockerfile or Compose file](/docs/guides/deploy-dockerfile-or-compose) and [One-click apps](/docs/guides/one-click-apps). ## Where it runs: the Build & deploy bar The wizard always opens on its configuration screen. At the top, a compact bar summarizes where the app will run and build (**Build & deploy:**, or **Build:** and **Deploy:** when they differ). Synq fills it in for you from your saved default or the server you picked last time; otherwise it uses this Synq host. Click the bar (it has a pencil) to open the target picker, **Where do you want to deploy?**: - One card per server. The Synq host itself carries a **This Server** badge (the current host, where deploys run by default). With several servers, **Choose a server** lists them with **Search servers…**. - **Add your own server** opens the **Add your server** form (name, IP address, port, username, and a password, SSH key or agent) right inside the wizard. The new server is selected once saved. See [Custom servers](/docs/guides/custom-servers). ### Advanced Pick a server and an **Advanced** section appears (collapsed by default). Its summary shows the current build location; expand it for: - **Runtime**: how the app is isolated on the server. - **Sandboxed** (recommended): an isolated container; a compromise cannot reach the host. Tiny overhead. - **Direct**: runs straight on the host. Lowest overhead, but full host access if compromised. Picking it shows a security caveat, and a memory note on small servers. - **Build location**: **This Machine** (build here and ship the output; faster on a powerful machine) or **Remote** (build on the deploy target; best when this machine is small). - **Clone location**, for sandboxed and Compose deploys: **On Synq** (clone on the Synq host, then upload; works everywhere) or **On the server** (clone on the server, no upload; best for big repositories). - **Rollback & backups**: how many past versions stay restorable on this server, and the project's pre-deploy backup policy. A clone on the server needs a credential the server can use: its own git login, a token or SSH key saved for that server, a clone token, or a GitHub App. See [Git authentication for private repos](/docs/guides/git-authentication). Tick **Save as my default for every deployment.** to remember the target for next time (change it later in Settings, or per deploy from this picker), then press **Continue**. ## The configuration screen The main column holds the settings; a sticky sidebar on the right holds the source, the domain, the **Deploy** button and a summary. For most apps the detected defaults are right and you can press **Deploy** straight away. ### The main column What renders depends on what Synq detected (see [Build detection and builders](/docs/guides/build-detection)): - **App**: a **Framework** picker (**Detected**, **Change**, **Use detected**) and the build settings: install command, build command, output directory, source folder, start command and port. - **Dockerfile Detected**: a single Dockerfile project ("Your project will be built and deployed using its Dockerfile"); you mainly confirm the **Exposed Port**. - **Services** (Docker Compose): the parsed services and their **Shared environment**. See [Compose & multi-service apps](/docs/guides/compose-multi-service). - **Monorepo**: a workspace header with one card per detected sub-app. Below that, depending on the project: - **Environment Variables** (collapsible; **Paste .env** and **Upload .env** help). See [Environment variables](/docs/guides/environment-variables). - **Compose file**: point at a Compose file outside the root ("Deploying with Docker Compose? Point to the file."), then press **Scan**. - **Health checks**: how Synq decides the new version is ready before switching traffic. - **Builder** (single apps on your own servers): **Auto**, **Dockerfile**, **Nixpacks**, **Railpack** or **Buildpacks**. Collapsed and on **Auto** unless you open it. See [Choose a builder](/docs/guides/build-detection#choose-a-builder). - **Project Name**. - **Routing**, when rewrites, redirects or headers were detected. ### The sidebar **Repository** shows `owner/repo` and a branch dropdown. Its menu offers **Copy clone token** (a ready-to-run `git clone` with a short-lived token, for GitHub App repositories). Uploaded and local sources have no remote repository, so they show no clone menu. **Domain** holds one or more domain rows (**+** adds one). Each row is a **Free subdomain**, a **Custom domain**, or **None** (internal only), plus the exposed **port** for server apps or the static path for static sites. To put the app on your own address with HTTPS, see [Custom domains](/docs/guides/custom-domains). A free subdomain is `.`: the apps domain set on the server or in **Settings**, **Instance**, **Apps domain**, else the panel's own domain, else the server's IP through sslip.io (`.203-0-113-7.sslip.io`). Synq saves it as an ordinary custom domain that happens to sit under the apps domain, so it is routed by your own edge and gets a Let's Encrypt certificate like any other domain. An apps domain needs the wildcard DNS record `*.` pointing at the server; an sslip.io one needs no DNS. A server with no public IPv4 address and no apps domain offers custom domains only. See [Free subdomains](/docs/guides/custom-domains#free-subdomains). **Deploy Summary** is a read-only recap at the bottom of the sidebar. For apps it lists the **Domain**, **Build Location**, **Framework**, and the **Install**, **Build** and **Output** settings. For Docker and Compose it shows the **Runtime** or **Stack** and the **Port**. ### The Deploy button The primary button in the sidebar reads **Deploy** and switches to **Deploying…** while it starts. Pressing it starts the build and takes you to the build screen. A few checks can interrupt first; none are errors, just the wizard asking for what it needs: - **Compose services with ports but no public domain**: a "No public service is reachable" warning with **Review Services** and **Deploy Anyway**. - **No way to clone a private repository** (no `gh`, no GitHub App, no token): a credential dialog offering to install the App, paste a token, or build locally instead. When you open this screen from a project's **Configuration** tab (with **Edit**), the button becomes **Save changes**: it writes the settings back to the project and returns you to that tab. Deploying is then the separate **Redeploy** action. See [Deployments, rollback & redeploy](/docs/guides/rollback-redeploy). ## The live build screen **Deploy** takes you to `/build/`, the screen that watches the deployment. It has three parts. ### Header and progress The heading is the project's name with a status pill next to it: **Building** or **Deploying** while it runs, then **Ready**, **Ready with warnings**, **Failed** or **Cancelled**. The source and branch sit under the name. Below it, a **step tracker** lights up each phase (clone, build, deploy and so on), with a spinner on the current step and a red mark on a failed one. ### Deployment Logs The **Deployment Logs** panel streams the build output line by line. This is where you read what actually happened. After a successful deploy of a server app, the same panel switches to the running app's container logs; a failed deploy adds a "See logs for issue details" hint. See [Logs & monitoring](/docs/guides/logs-monitoring). ### Details and actions The **Details** card on the right lists **Instance**, **Build**, **Build time**, **Framework** and **Domain** (**Domains** when there are several). The buttons change with the state: | State | Buttons | |---|---| | Building or deploying | **Stop Deployment** | | Failed or cancelled | **Open project**, **Edit Configuration** and **Redeploy** | | Ready | **Open project**, **Edit Configuration** and **Open site** | Read the last lines in Deployment Logs; that is the real reason. Most first-time failures are a missing build command, a missing environment variable, or the app listening on the wrong port. Fix it, then press **Redeploy**. See [Troubleshooting → Deployments](/docs/troubleshooting/deployments). ## Related guides