Technical walkthrough

Your code becomes
a production system.

Follow one backend from repository conventions to generated Kubernetes resources, then from a fast local loop to an observable release in your cloud.

Same code.Same contract.Different environments.
Start with the repository
01

Your repository

Structure declares intent.

Sol discovers application units from a small, explicit convention. The suffix says how a unit runs; the domain path says who owns it.

  • _svc is a long-running HTTP service
  • _worker consumes background work and events
  • _fn runs once or on a schedule

service · HTTPworker · Kafka consumerfunction · scheduled

myapp/

├─ app/

│  ├─ accounts/

│  │  └─ accounts_svc/

│  ├─ billing/

│  │  └─ reconcile_fn/

│  ├─ checkout/

│  │  └─ checkout_svc/

│  └─ payments/

│     └─ payment_worker/

├─ db/migrations/

├─ events/

├─ sol/

│  └─ prod/aws/us-east-1.yml

└─ sol.yml

_svc
accountsHTTP API · :8080
_fn
reconcileCron schedule
_svc
checkoutHTTP API · :8080
_worker
paymentKafka consumer

Each unit can carry its own sol.toml; the workspace root holds sol.yml and the target overlays under sol/<env>/<provider>/<region>.yml.

02

Sol builds a plan

Conventions compile into a complete system.

Sol combines repository structure, sol.yml, the selected destination, and safe defaults into one inspectable deployment model.

Repository analysis

  1. Discover domains and units
  2. Classify service, worker, or function
  3. Read configuration and destination
  4. Apply conventions and defaults
application: myappdestination: prod/aws/us-east-1units:  accounts_svc → service  reconcile_fn → scheduled job  checkout_svc → service  payment_worker → workerrelease: digest pinned

The plan is conceptual here; the CLI exposes the resulting resources and release evidence through the supported deployment and inspection commands.

03

Generated resources

Each primitive becomes ordinary Kubernetes.

Sol targets an open substrate in your account. The generated resources remain recognizable, inspectable, and operable with the tools you already use.

checkout_svcservice
DeploymentServiceConfigMap / SecretIngress optional
payment_workerworker
DeploymentConfigMap / SecretConsumer identity
reconcile_fnfunction
Job / CronJobConfigMap / SecretRun evidence

These are emitted together as one set per unit — not a pipeline. Namespaces and service accounts are generated alongside them.

04

Configure and customize

Strong defaults. Explicit escape hatches.

Sol derives what it can and makes the remaining decisions visible. You configure application intent—not a second copy of the underlying platform.

# app/checkout/checkout_svc/sol.toml — every field is optional
[infra.scale]
replicas = 3
cpu      = "250m"
memory   = "256Mi"

[infra.env]
config  = { LOG_LEVEL = "info" }
secrets = ["DATABASE_URL"]

[infra.rollout]
strategy = "canary"
steps    = [10, 40, 100]   # % of traffic
Sol infers

Unit type · resource shape · service discovery · probes · observability labels · build identity

You choose

Destination · scaling · resource limits · external access · environment values · advanced overrides

05

Local to production

Increase realism without changing the contract.

Move from native-process feedback to production-shaped containers, then to Kubernetes in your cloud. Each stage answers a different question without inventing a different application model.

Fast loopsol local runNative processesOne build · hot feedback
Production-shapedsol upLocal KubernetesReal containers · real charts
Your cloudsol deploy prod/aws/us-east-1Managed KubernetesAWS · GCP · conformant clusters
Same application contract PORT · /healthz · /metrics · SIGTERM
06

Inspect, operate, iterate

The evidence survives the terminal.

Status, releases, logs, metrics, traces, and rollback are part of the same workflow. When something fails, Sol connects the application model back to the Kubernetes evidence.

$ sol statusUNIT            KIND    STATUScheckout_svc     service  Runningpayment_worker   worker   Runningreconcile_fn     job     Succeeded$ sol logs checkout_svcINFO  server started on :8080INFO  GET /healthz 200 3ms
Observe

Prometheus metrics, Loki logs, Grafana dashboards, and trace context are wired to the unit identity.

Recover

Inspect release records, diagnose rollout state, and use sol rollback when a release should be reversed.

You keep control

The resources run in your cloud. Inspect or modify them with standard Kubernetes tools—and keep them if you stop using Sol.

One model, end to end

Ready to see the real workflow?

The repository tutorial walks through the current pre-alpha CLI and the exact commands it supports today.

Open the tutorial ↗Back to Sol