Skip to content

From first commit to global scale.

The control plane for every application, service, and database you run—self-hosted on your own infrastructure.

git push origin main
Northstar Foundry Waypoint Relay Mosaic Meridian

One operational language from source to service.

Cynone brings deployment, runtime, data, access, and signals into one workspace while keeping infrastructure choices explicit. Edge delivery, function-style runtimes, and scaling appear when the connected infrastructure supplies them.

Source delivery

Git-based deployments

Connect public or private repositories, preserve branch and commit context, and trigger repeatable application builds.

main

production

8e2f41a · deploy queued

Preview environments

pr-184.preview.example

Isolated branch configuration

Delivery layer

Global edge delivery on attached providers

Optional

Attach the CDN or global ingress provider you operate. Cynone keeps domains, TLS, and application routing connected to the release.

Ingress

Runtime

Signals

Workloads

Containers and background workers

Run web processes, queues, scheduled jobs, and supporting services with separate commands and resource controls.

web running
worker running
scheduler ready
redis healthy

Data plane

Managed databases

Provision and operate supported data services beside the applications that use them, with backups and lifecycle controls in context.

PostgreSQL Primary
Redis Cache
MongoDB Documents

Configuration

Environment variables and secrets

Separate preview and production values, keep sensitive data masked, and make configuration changes explicit.

APP_ENV production plain
DATABASE_URL •••••••••••• secret
FEATURE_CHECKOUT enabled plain

Custom domains and SSL

Route domains and manage certificate lifecycle.

Team permissions

Keep resource operations aligned with workspace roles.

Serverless functions on compatible targets

Use function-style runtimes only where the connected deployment model supports them.

Operations

Logs and observability

Read deployment and runtime output alongside health and resource signals.

GET /health 200

queue:work processing

backup scheduled

Automatic scaling on compatible targets

Apply replicas and capacity behavior only on compatible infrastructure targets.

The path to production stays visible.

Connect source once, let every commit create traceable deployment context, and choose the runtime topology that fits your infrastructure.

Select source

Example repository connection

Git provider

example/api-service

Private repository

main

8e2f41a · current production

feature/billing-events

6b97c0d · preview candidate

Commit context

Handle idempotent webhook delivery

Example Author · just now

Framework
Laravel
Build pack
auto-detected
Target
production

Deployment 215

feature/billing-events · 6b97c0d

Ready

00:01 repository cloned at 6b97c0d

00:04 framework detected: Laravel

00:12 dependencies restored from cache

00:31 container image assembled

00:37 health check responded

00:38 preview domain attached

Preview URL

billing-events.preview.example

Production

api.example.com

Trigger

Git push

Runtime topology

Example multi-target architecture

Infrastructure-dependent
01

Gateway

TLS + routing

02

Runtime

Apps + workers

03

Data

Managed services

Replicas

Configure on compatible targets

Delivery

Attach your preferred edge network

Signals

Keep health and logs in context

Every request has a legible path.

Model ingress, runtime, data, and signals as connected systems. Optional global network and scaling layers follow the infrastructure you attach.

01

User request

HTTPS ingress

02

Global network

Optional CDN / gateway

03

Application runtime

Web + workers

04

Database or service

State + dependencies

05

Observability

Health + logs

Health and delivery reflect the systems and providers attached to your instance. signals attached

The command line and control plane agree.

Trigger a real deployment through the authenticated API, then inspect build detection, configuration, preview URLs, and logs in the workspace.

Authenticated API workflow

# install an API client if needed (Debian / Ubuntu)

sudo apt-get install -y curl

# one-time shell setup

export CYNONE_URL="https://your-instance.example"

export CYNONE_TOKEN="••••••••••••"

# deployment command

curl -fsS -X POST \

"$CYNONE_URL/api/v1/deploy?uuid=app_uuid" \

-H "Authorization: Bearer $CYNONE_TOKEN"

# example response

✓ Deployment queued

deployment_uuid: dp_01jexample

Detected framework

Laravel ready

Environment

production 12 variables

Fast iteration without invisible infrastructure.

01

Performance

Keep build cache, runtime configuration, and resource controls close to the deployment that uses them.

  • Build context
  • Resource limits
  • Health checks
02

Reliability

Inspect release history, logs, backups, and rollback context while defining reliability objectives around your infrastructure.

  • Deployment history
  • Backups
  • Rollbacks
03

Collaboration

Organize teams, projects, and environments with role-aware access to production operations.

  • Team roles
  • Projects
  • Environment boundaries
04

Security

Use encrypted secrets, TLS domains, API token abilities, and explicit confirmation for sensitive actions.

  • Secret handling
  • TLS lifecycle
  • Scoped tokens

Know what Cynone controls—and what stays yours.

Cynone manages the control-plane workflow. Your servers, networks, credentials, and provider configuration remain explicit parts of the operating model.

Identity

Email/password, available OAuth providers, two-factor challenges, and recovery codes.

Access

Team roles, resource policies, and scoped API abilities for read, write, and deploy operations.

Configuration

Masked secret values and encrypted storage for supported sensitive fields.

Transport

Custom domains, proxy routing, and certificate lifecycle on connected infrastructure.

Choose the operating model, then price the infrastructure.

Cynone adapts to the operating model configured for your instance. Review the available options in your workspace or plan an enterprise rollout with the engineering team.

Self-managed

Bring your infrastructure.

Operate Cynone on servers and providers you control. Infrastructure and operations costs remain with your chosen vendors.

Start deploying

Enterprise

Design the operating model together.

Discuss team structure, infrastructure topology, security boundaries, and support requirements before rollout.

Talk to an engineer

Make the first deployment

Build the release path your team can trust.

Connect a repository, choose your infrastructure, and keep every deployment decision in one operational workspace.