Skip to content
Satusky Docs

Introduction

Satusky takes your Dockerfile and runs it on managed Kubernetes infrastructure. You do not need to know Kubernetes. You do not need a local Docker daemon. You push code; Satusky handles everything between your source and a live HTTPS endpoint.

What Satusky is

Section titled “What Satusky is”

Satusky is a container deployment platform. The deployment model is simple:

  1. You write a Dockerfile.
  2. You run 1ctl deploy.
  3. Satusky builds the image in the cloud using Kaniko, pushes it to an internal registry, creates a Kubernetes Deployment, and wires up a public route with a hostname.
  4. Your app is live.

That’s the whole loop. No cluster configuration, no image registries to manage, no kubectl.

Key concepts

Section titled “Key concepts”

Before you deploy your first app it helps to understand the object model. There are five concepts worth knowing.

Organizations

Section titled “Organizations”

An organization is the top-level billing and access control boundary. Everything — namespaces, deployments, domains — lives inside an organization. When you sign up you get a default organization. You can create more to separate teams or clients.

Machines

Section titled “Machines”

Machines are the bare-metal hosts or VMs that form the underlying Kubernetes clusters. You do not interact with machines directly in the normal deployment flow, but they appear in status output and are relevant when you’re thinking about placement, regional distribution, or capacity.

Namespaces

Section titled “Namespaces”

A namespace is an isolation boundary within an organization. Think of it like a project or environment. Deployments in production and deployments in staging are completely isolated from each other even though they share the same organization.

Every deployment belongs to exactly one namespace.

Deployments

Section titled “Deployments”

A deployment is your running application. It maps to a Kubernetes Deployment under the hood. A deployment has:

  • An image (built from your Dockerfile)
  • Resource limits (CPU and memory)
  • Environment variables and secrets
  • A replica count
  • A port it listens on (default: 8080)

Public Routes and Domains

Section titled “Public Routes and Domains”

A public route is the routing rule that connects a hostname to a deployment. Satusky provisions a default subdomain for every deployment automatically. Current deploys use Gateway API routes by default; the legacy 1ctl ingress documentation is historical/manual context. You can attach your own domain by adding a DNS record and running 1ctl domains add.

How Satusky differs from other platforms

Section titled “How Satusky differs from other platforms”

No local Docker required. Builds run in the cloud via Kaniko. You only need the 1ctl binary on your machine.

No Kubernetes knowledge required. The CLI and config file (satusky.toml) give you a mental model that maps directly to what you already know: containers, ports, environment variables, scaling. The Kubernetes layer is an implementation detail.

Multi-cluster out of the box. Satusky supports active-active and active-passive multi-cluster configurations. You can deploy to multiple regions from a single satusky.toml without managing cluster credentials or contexts.

Billing

Section titled “Billing”

Satusky uses a credit-based billing model. Credits are consumed by running deployments based on the CPU and memory they reserve. You can view your credit balance and usage with 1ctl credits balance. See the billing reference for the full rate table.

Section titled “What to read next”