An open API service indexing awesome lists of open source software.

https://github.com/thijsrijkers/torso

A self-hosted infrastructure engine
https://github.com/thijsrijkers/torso

cloudformation go hosting open-source self self-host self-hosted self-hosting

Last synced: 14 days ago
JSON representation

A self-hosted infrastructure engine

Awesome Lists containing this project

README

          

# Torso

**Torso** is an open source, self-hosted infrastructure orchestration engine written in Rust. Define your infrastructure, databases, applications, DNS, load balancers, and more in a declarative `.Torso` file, and let Torso handle the rest.

Think of it as CloudFormation, but one you own, run yourself, and extend however you want.

---

## How it works

Torso runs as a long lived HTTP server on your infrastructure. You bootstrap it once using the CLI with an initial environment file. After that, everything is driven by HTTP request an `.Torso` file to the server, and Torso will reconcile your desired state with reality.

```
Torso init --file environment.Torso # Bootstrap your environment
Torso serve # Start the Torso HTTP server

curl -X POST http://localhost:7070/apply \
-H "Content-Type: application/x-Torso" \
--data-binary @my-service.Torso # Deploy a new service
```

No proprietary dashboards. No cloud lock in. Just Rust, HTTP, and a file.

---

## The Torso File

An `.Torso` file is a declarative YAML based configuration that describes the desired state of a resource or environment. It follows a simple `kind` + `spec` structure:

```yaml
kind: Database
metadata:
name: my_postgres
spec:
engine: postgres
version: "15"
storage: 20Gi
replicas: 1
```

```yaml
kind: App
metadata:
name: my_api
spec:
image: ghcr.io/myorg/api:latest
port: 8080
replicas: 2
env:
- name: DATABASE_URL
value: postgres://...
```

Torso reads the `kind` field and routes it to the correct provisioner under the hood.

---

## Design Principles

- **Self hosted first** — Torso runs on your hardware, your cloud, your rules.
- **File driven** — everything is defined in an `.Torso` file. No hidden state in a UI.
- **HTTP native** — the engine is an API. Automate it, wrap it, integrate it.
- **Pluggable** — providers are first-class. Torso doesn't dictate where you run.
- **Rust all the way** — single binary, fast startup, easy to deploy Torso itself.

---

## Roadmap

### Phase 1 — Core Engine
- [ ] Define the `.Torso` file specification (YAML-based, `kind` + `spec` pattern)
- [ ] Build the CLI (`Torso init`, `Torso serve`, `Torso apply`, `Torso status`, `Torso destroy`)
- [ ] Bootstrap environment from an initial `.Torso` file via `Torso init`
- [ ] Start the Torso HTTP server via `Torso init`
- [ ] Accept `.Torso` file payloads over HTTP `POST /apply`
- [ ] Parse, validate, and route resource kinds to their provisioners
- [ ] Basic state tracking, know what has been created, updated, or removed

---

### Phase 2 — Database Provisioning
- [ ] Provision PostgreSQL instances
- [ ] Provision MySQL instances
- [ ] Provision Redis instances
- [ ] Support configurable storage size, version, and replica count
- [ ] Lifecycle management, create, update, and destroy
- [ ] Connection string output exposed after provisioning

---

### Phase 3 — Application Hosting
- [ ] Deploy containerized applications from an image registry
- [ ] Configure environment variables and secrets
- [ ] Set replica count and resource limits (CPU/memory)
- [ ] Rolling deploy support, update without downtime
- [ ] Health check configuration (HTTP or TCP)
- [ ] Restart policies and crash recovery

---

### Phase 4 — DNS Management
- [ ] Register and manage DNS records (A, CNAME, TXT, MX)
- [ ] Attach a domain to a deployed application automatically
- [ ] Support multiple DNS providers (Cloudflare, Route53, etc.) via pluggable drivers
- [ ] TTL configuration per record
- [ ] Automatic DNS cleanup on resource destroy

---

### Phase 5 — Load Balancer
- [ ] Create and configure HTTP/HTTPS load balancers
- [ ] Route traffic to one or more application instances
- [ ] Support round-robin and least-connections strategies
- [ ] SSL/TLS termination with automatic certificate provisioning (via Let's Encrypt)
- [ ] Health-check-aware routing, remove unhealthy instances automatically

---

### Phase 6 — Secrets & Configuration
- [ ] Secrets store, store and inject secrets into apps at deploy time
- [ ] Support referencing secrets inside `.Torso` files via `${{ secret.name }}` syntax
- [ ] Encryption at rest for stored secrets
- [ ] Secret rotation support

---

### Phase 7 — Networking & Firewalls
- [ ] Define virtual private networks (VPNs/VPCs) and subnets
- [ ] Configure firewall rules, allow/deny by port, protocol, and CIDR
- [ ] Private networking between services (service discovery by name)
- [ ] Public/private toggle per service

---

### Phase 8 — Object Storage
- [ ] Provision and manage object storage buckets
- [ ] Configure bucket policies (public read, private, etc.)
- [ ] Mount buckets as volumes in application containers
- [ ] S3 compatible API support

---

### Phase 9 — Observability
- [ ] Expose resource status via `GET /status/:name`
- [ ] Structured event log per resource (created, updated, failed, destroyed)
- [ ] Metrics endpoint (`/metrics`) compatible with Prometheus
- [ ] Deploy time dry run mode, validate a file without applying it (`POST /plan`)

---

### Phase 10 — Provider System
- [ ] Pluggable provider architecture, write your own provisioner in Rust
- [ ] Official providers: Docker, Kubernetes, DigitalOcean, Hetzner, AWS
- [ ] Provider registry, install providers via `Torso provider add `
- [ ] Provider versioning and pinning inside `.Torso` files

---

## Contributing

Torso is in early development. Contributions, ideas, and feedback are very welcome. Open an issue or a pull request.

---

## License

Apache 2.0