Serverless deploy

Apps that scale on their own — from marketplace to runtime.

In Deploy, developers run their own apps on the eQuantic Cloud as serverless services that scale automatically, including to zero when idle.

Create a service#

The wizard is a marketplace by category. The Custom category (default) covers four sources:

The other categories bring ~40 ready-made open-source services (Postgres, Redis, RabbitMQ, MinIO, Grafana, n8n, Metabase, Keycloak, WordPress…), each with its own installation form.

Operate the service#

• Overview with CPU/memory charts and source/build.
• Deployments with a live build stream and rollback.
• Scale & resources — scale triggers (KEDA), scale-to-zero, instance range, and CPU/memory editable at any time — resizing a running service rolls it forward with the new share, no recreate.
• Health check — point the platform at your app's own probe endpoint, and override the container's command/args when the image's defaults aren't yours.
• Interactive Console (drawer), live runtime logs, variables and domains (automatic TLS).
• www on any custom domain — one switch per domain, either redirecting www.example.com to example.com with a 301 (the default, and what search engines want: two hosts serving identical content are two canonical URLs for one page) or serving both. Pointing a www CNAME at us is not enough on its own: DNS resolves the name, and which host answers — and which certificate is issued — is decided afterwards from the request, so the domain has to claim www for the platform to route it and issue TLS for it.
• The service's own address — on the Domains tab, choose the name a service answers at under the platform's domain: cura-accounts.apps.equantic.space in place of the generated cura-accounts-e49f09.apps.equantic.space. The generated address keeps working, with a 301 to the chosen one that keeps the path and the query, so a link already shared does not break. A name is first come, first served across the platform, and one given up is free for anyone at once. Every address on the tab has a copy button.
• Advanced configuration (EXPERT) — resource/probe overrides and inspection of the generated manifest.

The wizard's advanced settings carry the same knobs at creation time — resources and instance range chosen there are what the first deployment runs with.

Open Pull Requests can also get ephemeral preview environments, deployed like regular services and destroyed automatically on merge/close — see Repositories & CI/CD.

Where a version came from#

A service's Overview says which version is running and, when the image is one of ours, where it came from: the pipeline run that pushed it, the commit behind that run, and the repository. The run page answers the same question from the other end, with a Deployed to strip naming every environment its images are running in.

The link is recorded, never guessed. A job that pushes with the token the platform already injects is attributed to that run:

- run: docker login registry.equantic.space -u eqs -p $EQS_TOKEN
- run: docker push registry.equantic.space/acme/api:${{ github.sha }}

An image pulled from a registry we do not run has no provenance, and the screen says so rather than showing an empty panel.

Reaching one service from another#

A service's connection string names it in full — postgres.p-1a2b3c-production.svc.cluster.local — rather than just postgres. The short name resolves only inside the Space it belongs to, and a Space is a Kubernetes namespace: an app in another Space that was handed the short name worked until something restarted it, then could not resolve its own database.

Copy the connection from the service's Connect panel (or eqs db url <service>) and it works from anywhere in the workspace.