Using the workspace
Deploy your app
Ask Dus to put your app online, on your own server over SSH or a hosting provider. It asks for what it can't know, checks the live site, and can roll back.
Deploying is a task like any other. Say "Put it online" and Dus does the work: it inspects the project, picks how to run it, plans the steps, deploys, and checks the live address. Your part is to answer what only you know, approve what costs money or touches production, and say whether the result is right.
Start a deploy
Type "Put it online" in the message box, or use the Deploy card:
- Click the project's name at the left of the top bar.
- Choose Project details (or click the project you're in, which is ticked).
- Click Put it online on the Deploy card.
Dus reads the project first: the framework, the build and start commands, the port, a Dockerfile, the database and its migration command, and the environment variables the code expects. It then recommends a way to run it (Docker, Node, Python or a static site) and shows the steps as the task's plan.
What Dus asks for
What Dus can't know, it asks for with a Needs you form in the chat: for example the server's address, the SSH user and key, a domain, or a hosting token. Secrets in the form go straight into your vault and never reach the AI. Click Save and continue to carry on, or Not now to stop.
Dus asks once per project. It saves the deploy target (where to deploy, and the names of the vault secrets it needs) in your Duscode home folder, not in the project, so server addresses never end up in a commit. The next deploy is one step.
Where it can deploy
Your own server, over SSH
Give Dus a Linux server you can reach over SSH (Debian, Ubuntu or a Red Hat family system). Dus:
- installs what the app needs (Docker, Node 22 or Python), the Caddy web server and a firewall (the SSH port stays open)
- uploads the release, without
.envfiles,.gitornode_modules, and writes the app's environment from the vault - builds it, runs database migrations (after you approve), and starts it as a service that restarts on its own
- serves it through Caddy, with HTTPS from Let's Encrypt when you give a domain
- checks that it answers, on the server and from your machine
The new release and the previous one are kept. If the new one fails its health check after the switch, Duscode goes back to the previous release automatically.
A hosting provider
Dus can deploy through the official command-line tool or API of Vercel, Netlify, Fly.io, Render and Cloudflare Pages, with your token from the vault. These flows follow each provider's public documentation and have not yet been tried against live accounts, so check the result on the provider's own dashboard the first time.
For other providers, such as DigitalOcean, Hetzner or AWS Lightsail, Dus can use their command-line tools in ordinary commands. Creating a server there is a decision that costs money, so Dus asks first.
Owner decisions
Some steps are always yours to decide, whatever the permission mode. They show as a Needs you card with a red tag:
| Tag | When |
|---|---|
| Production | The first deploy to a target |
| Costs money | A deploy that creates billed resources, such as on Fly.io or Render, or creating a server |
| Database migration | Running the app's migrations |
| DNS change | Changing DNS records |
| Destructive | A command that deletes or overwrites data on a server |
The card says what will happen and To undo: how to reverse it. Choose Approve or Reject. There is no Always allow on these cards, and no rule or mode skips them. A redeploy to a target you've already used, and a rollback, are ordinary approvals.
Is this what you wanted?
Every task that did something ends with two lists: What Dus did and How it was checked (the checks that ran, the deploy's health check and live address, browser checks). If nothing checked it, it says so.
Answer Looks good, or Change something to put the cursor in the message box so you can say what to change. If the plan stopped part-way, Continue picks it up again.
The Deploy card
The Deploy card in Project details is the one place for your deploys. For each target it shows its kind (Server, Vercel, Netlify, Fly.io, Render or Cloudflare), its status (Live, Last deploy failed or Rolled back), Where, the live Address, and the Last deploy.
- Deploy again asks Dus to deploy the current code to that target.
- Rollback puts the previous release back, after a health check. You confirm with Roll back; your click is the approval. Deploy again to return to the newer code.
Limits
- Caddy is the only web server Dus sets up on a server.
- Dus doesn't buy servers or domains for you, or automate DNS.
- Databases aren't backed up before a migration. Back up first if the data matters.
- The terminal app can deploy, but has no acceptance step.