Managed remote vs self-managed remote
When to pick which path — capability, control, and cost tradeoffs.
Syntax supports two ways to run models on remote hardware:
- Self-managed remote — your own SSH-reachable boxes, you own the hardware and the OS, Syntax handles the engine and lifecycle.
- Managed remote (dUX) — dUX manages the hardware on your behalf, in your own cloud accounts. You describe the deployment intent; dUX handles provisioning, placement, and scaling. You remain the sole admin and can take over directly any time you need to.
Each has the right place; this page lays out the tradeoffs.
Side-by-side
| Self-managed remote | Managed remote (dUX) | |
|---|---|---|
| Hardware admin | You | You — dUX orchestrates, you retain full admin |
| Cloud account | N/A | Yours; dUX operates within it |
| GPU drivers | You install once | dUX installs and updates |
| Autoscaling | None (single host or multi-host you control) | dUX, automatic |
| Replica management | Manual | Automatic |
| Setup time | Provisioning your own host | Minutes — pick a tier |
| Network | Whatever your host has | Cloud-grade ingress |
| Predictable cost | You know your bill (it's your hardware) | Hourly on the cloud you've authorized |
| Privacy | Highest — you own the box | High — your cloud account, dUX-orchestrated, isolated per org |
| Best for | Power users with hardware; teams with strict data residency | Teams that want managed cloud GPU without giving up admin |
When self-managed remote is the right answer
- You already own GPU hardware that's underutilized.
- You want maximum control of the OS, drivers, and network.
- Data residency is a hard requirement and you can't put weights through dUX.
- You want SSH-level visibility into running processes for debugging.
When managed remote is the right answer
- You don't have GPU hardware.
- Your team needs autoscaling because traffic is bursty.
- You want a deployment that's always available without you babysitting it.
- You want sharing with teammates to be one click rather than manual SSH access.
Mixing both
Nothing prevents you from using both. A common pattern:
- A handful of "always available" managed remote deployments behind the org's Bridge.
- One or more self-hosted remote boxes for experiments, larger models, or workloads with strict data residency.
The Bridge routes per-request based on your model policy, so your harness sees one consistent set of model names regardless of where each one runs.