RailDock fits when
You want a centralized deployment and operations product while keeping infrastructure location and ownership in your hands.
Deployment model
Choose the abstraction boundary you actually want.
RailDock is for teams that want product-grade deployment operations on infrastructure they control. That is a different tradeoff from both a hosted PaaS and operating raw Dokku directly.
Model comparison
Same goal. Different ownership boundaries.
This table describes architectural models, not a winner. Third-party platform capabilities change; validate them against current documentation when evaluating a migration.
| Characteristic | RailDock | Hosted PaaS model | Raw Dokku model |
|---|---|---|---|
| Infrastructure ownership | Your servers | Provider infrastructure | Your servers |
| Web control plane | Built in | Common | CLI/plugin-led |
| Declarative project state | Built in | Varies | Not the core model |
| Execution over SSH/Dokku | Core engine | Usually no | Direct |
| Backup / recovery product flows | Integrated | Varies | Plugin / ops dependent |
| Organizations / activity / API | Control-plane resources | Common | External tooling often needed |
Hosted PaaS fits when
You want the provider to absorb more of the host and runtime operations boundary, accepting provider constraints in exchange.
Raw Dokku fits when
You prefer a smaller CLI-first primitive and are comfortable composing the surrounding operations experience yourself.
Evaluate from constraints
Read the architecture before choosing the platform.
Start with where workloads must run, who owns operations, and how much abstraction the team wants to maintain.