Dawnrose

Product Deploy

Deploy whatever your agent builds.

Point Dawnrose at code and it runs. No Dockerfile, no YAML, no cluster to look after.

webproductionDeployment #42 from acme/shop@a41c9e2
  1. 00:00Cloning acme/shop at a41c9e2
  2. 00:02Detected Node 22 from package.json
  3. 00:03npm ci
  4. 00:12added 412 packages in 9s
  5. 00:13npm run build
  6. 00:21next build, compiled successfully
  7. 00:48Image ready, 148 MB
  8. 00:51Starting 1 replica on port 3000
  9. 00:53Sandboxed with gVisor
  10. 00:55Healthcheck GET /health → 200
  11. 00:56Traffic moved to the new version
  12. 00:56Online at shop-k3f9.up.dawnrose.ai

Deployments

  • #42 Add coupon codesOnline
  • #41 Fix cart totalsReplaced
  • #40 Upgrade NextFailed
  • #39 Add product searchReplaced

Rollback

#41 and #39 can come back with their image, settings and variables. #40 failed, so it never took traffic.

webshop-k3f9.up.dawnrose.ai

Online#42, live 56 s after the push

Sample data

If it keeps crashing, the last good deploy comes back.

When a new deploy’s replicas crash 3 times in its first 10 minutes live, Dawnrose puts the previous one back by itself, with its image, settings and variables. You can turn it off per service.

  1. Deployment #43 goes live

    Built from acme/shop@b81f0d4. It passed its healthcheck.

  2. Its replicas crash

    Exit code 1, then a restart, 3 times over.

  3. #42 comes back

    The image, settings and variables it ran with. Nothing is rebuilt.

  4. The activity log says why

    “Rolled back web to dep_7hq2m4xk: the new deployment kept crashing (replicas crashed and restarted 3 times)”

Give every customer their own server.

Your own backend calls Dawnrose the way your agent does: create a project, send it code, get a live URL back.

provision.ts@dawnrose/sdk
import { Dawnrose } from "@dawnrose/sdk";

const dawnrose = new Dawnrose({
  token: process.env.DAWNROSE_TOKEN,
});

// a server for each customer, from your own code
const { url } = await dawnrose.deploy({
  project: `customer-${customer.id}`,
  service: "api",
  files: { "server.js": code, "package.json": pkg },
  variables: { CUSTOMER_ID: customer.id },
});
Online at api-k3f9.up.dawnrose.ai
Projectsone per customer, made by provision.ts
  • customer-1040api-q81d.up.dawnrose.aionline
  • customer-1041api-m4t7.up.dawnrose.aionline
  • customer-1042api-k3f9.up.dawnrose.aionline
  • customer-1043building from the files it was sentbuilding

deploy() resolves when it’s live, with the URL your code hands to the customer.

  • From code to a URL in one call

    It builds your files, image or repo, and resolves when the service is live.

  • A token per project

    Project tokens reach one project and nothing else in your workspace.

  • Your language

    SDKs for TypeScript, Python, Go, Ruby and PHP, or the REST API with its OpenAPI spec.

  • Call it from outside

    From your servers or CI. An app on Dawnrose can’t reach the API from inside its container.

Read the API and SDK docs

From code to a URL.

  • A repo, a folder or an image

    GitHub repos deploy on every push. Your agent or the dawn CLI can upload a folder. Any Docker image works too, private ones included.

    • acme/shopGitHub, branch main, deploys on push
    • ./workerA folder, from dawn up or your agent
    • ghcr.io/acme/report:1.4Any Docker image, private ones too
  • Config as code

    Keep build and deploy settings in dawnrose.json next to your code.

    {
      "build": {
        "builder": "AUTO",
        "buildCommand": "npm run build"
      },
      "deploy": {
        "startCommand": "node dist/server.js",
        "healthcheckPath": "/health",
        "numReplicas": 2
      }
    }
  • Migrations before traffic

    A pre-deploy command, such as your migrations, runs once on the new version before it takes any requests. If it fails, the new version never goes live.

    1. 00:41Image ready, 148 MB
    2. 00:42Running pre-deploy command: npm run migrate
    3. 00:44Pre-deploy command exited with code 1
    4. 00:44#43 stops here. #42 keeps serving.
  • Builds without a Dockerfile

    Node, Python, Go and static sites are detected and built. A Dockerfile in the repo is used when there is one.

  • Monorepos

    Point a service at a folder of the repository and only that part is built.

  • Healthchecks before traffic

    A new deploy takes requests only after it passes its healthcheck, or at least accepts connections, so a broken build never replaces a working one.

Smaller building blocks, too.

Function

One TypeScript or Python file, as an endpoint with its own URL or a job on a schedule. Edit it in the dashboard.

Bucket

S3-compatible storage with the bucket made and the keys checked. Apps read S3_ENDPOINT and S3_BUCKET.

Sandbox

A Linux machine with Node, Python and git where you or your agent can run commands.

Docker image

Anything that ships as an image, from Docker Hub, GitHub or your own registry.

Point it at code. Get a URL back.

Paste into your terminal, with the token from your dashboard
$ claude mcp add --transport http dawnrose \
    https://app.dawnrose.ai/mcp \
    --header "Authorization: Bearer YOUR_TOKEN"