Apps overview

Apps are long-running services built from a GitHub repository, a container image, or a folder on your machine. Synteq builds the image, runs each replica in its own microVM, and serves the app over HTTPS. Use apps for web servers, APIs, and workers that hold connections.

• Hostname: every app gets <name>.synteq.app with a TLS certificate, live when the first release passes its health gate.
• MicroVM isolation: each replica boots its own kernel in a Firecracker microVM. No kernel, filesystem, or process table is shared with another customer.
• Zero-downtime releases: a new release starts alongside the old one and takes traffic only after it passes a health check. If it never passes, the old release keeps serving.
• Rollback: redeploy any earlier release in one action, without a rebuild.
• Logs: build logs, a live tail, and searchable history.
• Environment variables and secrets: injected at build time, run time, or both.
• Custom domains: automatic certificates.
• Activity: an audit trail of who deployed, changed, or scaled what.

An app has one source at a time: a GitHub repository and branch, an image reference in a registry, or a folder uploaded with synteq deploy.

Apps, like all other resources, belong to a project. Select the organization and project in the sidebar before you create one. Creating or changing apps needs the Technical role, owner, or admin. Read-only members can view apps; billing members cannot.

Each app replica runs as a Firecracker microVM on a runtime node, a virtual machine on a Synteq host that runs only customer microVMs. Three replicas are three microVMs booted from the same image.

Each microVM has its own guest kernel, memory, root filesystem, and network interface behind a hardware virtualization boundary, with a firewall outside the guest, and CPU and memory are enforced per instance.

• Environment: replaced, not inherited. Your process sees only the variables you configured and the ones the platform injects.
• PORT: set to the port the platform probes and routes to. That is the port in the app's settings, or one detected from the image. Listen on PORT on all interfaces.
• Root filesystem: the root filesystem is writable but temporary. Writes are lost when the instance restarts or a new release rolls out, and the space available is limited by the instance's memory.
• Shutdown: the platform sends SIGTERM and powers the machine off after 10 seconds. Handle the signal to finish in-flight work.
• Persistent disk: keep any state that must survive a restart or release in a database, an object store, or another connected service. Apps are designed for ephemeral services, because replica scaling and blue-green deploys depend on it.

A release is one image digest rolled out to one app. Deploys, rollbacks, and replica changes all go through the same states. Rolls of one app run one at a time; different apps roll in parallel.

A rollback starts a new roll from an earlier release's image digest, with a new release number and the same health gate. Nothing is rebuilt and the source is not fetched again. Environment variables are read at roll time, so a rollback picks up variable changes made since. See Deploying and configuring an app.

A health check runs against each app every 15 seconds.

• Replacement: an instance whose process exited or that stopped answering is replaced with a fresh one from the same image, through the same probe.
• Backoff: repeated restarts wait 10 seconds, doubling up to 5 minutes. The backoff resets after 10 minutes healthy.
• No result: an instance with no probe result yet is not counted as failed.
• Leftovers: instances that belong to no current release, such as those from an interrupted roll, are removed after a short grace period.

The same check applies to replica changes and autoscaling. See Running and scaling an app.

• CPU: capped at the plan's share. A plan change that alters CPU applies to running instances without a restart.
• Memory: a soft cap. An instance that reaches beyond its RAM allocation will typically crash. Choose a plan with more memory or, where the plan offers it, bill memory overage instead.
• Disk: each instance has the image plus a temporary writable layer, which is limited by its memory and cleared on restart.

On the smallest paid shape, a plain Node.js service typically serves a few thousand requests per second at about 10 ms median latency, using about 120 MB of memory.

The gateway is the only internet-facing machine. It terminates TLS, routes by server name, and forwards each request to a live instance on PORT.

• Protocols: HTTP/1.1 at the edge, forwarded to your instance as HTTP. Only HTTP, HTTPS, and WebSocket traffic is routed; raw TCP and UDP are not exposed.
• WebSockets: supported and exempt from the request timeout. A connection idle in both directions for 5 minutes is closed; send a heartbeat to keep it open.
• Request timeout: 30 minutes, then the gateway returns a timeout. Run longer work as a background job the client polls.

All instances in a location leave through one shared outbound address. To allowlist it at a provider that filters by source IP, ask support for your location's address.

<name>.synteq.app is covered by a platform wildcard certificate and serves HTTPS from the first release.

A custom domain needs a TXT record at _synteq-challenge.<your domain> and a routing record: a CNAME to <name>.synteq.app for a subdomain, or an A record to the gateway address for a root domain (CNAME flattening also works). Once both resolve, Synteq issues a certificate, which renews automatically at a third of its lifetime. The domain moves through Pending DNS, Verifying, Issuing, and Live, or Failed with the reason shown. A domain is verified on one app at a time.

Every app has a primary location, chosen at creation, where its instances run and where its logs and metrics come from.

Synteq builds images with BuildKit on a build machine separate from the runtime fleet. The image is pushed to a private registry and addressed by its digest.

The mode is chosen on the server for every source. To use Railpack in a project with a Dockerfile, remove or rename the Dockerfile. For a Dockerfile outside the build root, set the Dockerfile path on the Settings tab.

• Build-time variables: variables scoped Build-time or Both are passed as build arguments. Declare them with ARG in a Dockerfile. Runtime-only variables are absent.
• Cache: the build machine may reuse layers from a recent build of the same app. A hit is not guaranteed, so put dependency installs before the step that copies your source.
• Release identity: the image digest. Two builds of the same commit are two releases.
• CLI uploads: .git, node_modules, .venv, and __pycache__ are excluded, along with anything your .gitignore or .synteqignore excludes, and .env files are never uploaded. The maximum upload size depends on your plan. Deploy larger projects from GitHub or as a pre-built image.
• Build logs: detection output, each step with timings, and the push with its digest. Open any build from the Deployments tab. A release that failed its gate also keeps the instance output, with the last line as the failure reason.

Connecting GitHub installs the Synteq GitHub App and links one repository and one branch to the app. Only a push to the linked branch builds. The release records the commit message, short SHA, and author.

Pushes to other branches, tag pushes, branch deletions, and pull request events are ignored. A merged pull request builds when its merge commit lands on the linked branch.

Options under Settings > Build and deploy:

Build filters apply ignored patterns first. If included patterns are set, at least one remaining file must match one. If no file remains, the push is skipped. Patterns are shell globs, not gitignore rules: * matches across /, so docs/* matches docs/a/b/c.md, and ** is the same as *.

Each app follows one branch, and re-linking replaces the previous link. To run two branches, create two apps. For a monorepo, create one app per service, each with its own root directory and included paths.

Not supported:

• Preview or pull request environments.
• Environment promotion.
• Tag-triggered releases.
• Git hosts other than GitHub, or pushing to Synteq over git.
• A platform configuration file in the repository. Settings live on the Settings tab and in the CLI. Your Dockerfile and Railpack's configuration files are honoured.

A plan sets the CPU and memory per instance, the replica limit, and which optional features are available: autoscaling, and additional locations. Plans are monthly and include a set number of replicas; extra replicas are priced per replica.

• Free tier: needs a card or PayPal account on file, which is not charged. Paid tiers are charged at creation.
• Plan changes: upgrades are prorated. Downgrades apply at renewal by default; you can choose to apply them immediately for a prorated credit.
• Overage: on plans that allow it, each axis (CPU, memory, bandwidth) is billed, throttled, or both past its allowance. Accrued overage is added at renewal.
• Optional features: features with a monthly fee are billed only while on.
• Cancellation: the app runs to the end of the billing period and does not renew. It can be recovered until then and for seven days after.

See Running and scaling an app.

App statuses:

Deploying and configuring an app first deploy from GitHub or the CLI, environment variables, custom domains, and rollbacks.

Running and scaling an app plans, replicas, autoscaling, locations, logs, the console, and cancelling.

Functions overview request-driven code that costs nothing while idle.

Getting started with the CLI install and sign in to synteq.