DawnroseDocs Operate
Scaling and plan limits
You scale a service by running more replicas or by giving each replica more CPU and memory. How far you can go depends on the workspace’s plan. You pay for the resources your services use, within a spend limit.
CPU and memory
Under Settings → Deploy, CPU limit (vCPU) and Memory limit (MB) set what each replica may use. Left empty, a replica gets the plan’s default CPU and memory, listed below, or the size of the server it runs on if that is smaller. A replica that goes over its memory limit is killed and restarted according to its restart policy.
You are billed for what the replicas actually use, not for the limit. A replica’s memory limit is set aside for it on its server, so neighbours can’t take it. A workspace can hold what its balance would pay for over 7 days at $10 per GB a month, or a small app’s worth (2 GB on Trial, 4 GB on Hobby, 8 GB on Pro), whichever is more. Only growing needs the balance: redeploying what already runs, or rolling back, works when money is low.
Replicas
Replicas sets how many copies of the service run. The edge spreads requests across them in turn. Each replica has its own filesystem, and a service with a volume always runs one replica. Cron services run one container per run, whatever the setting.
Changes to limits and replicas are staged and apply on the next deploy. If a service keeps hitting its limits, Dawnrose suggests a change; see Scaling advice.
Plans
| Trial | Hobby | Pro | |
|---|---|---|---|
| Price | $0 | $5 a month | $20 a month |
| Projects | 2 | 20 | 100 |
| Services per project | 5 | 30 | 100 |
| Services in the workspace | 10 | 200 | 1,000 |
| Environments per project | 2 | 10 | 50 |
| Pull request environments | No | Yes | Yes |
| vCPU, per service | 1 | 8 | 32 |
| Memory, per service | 1 GB | 8 GB | 32 GB |
| vCPU when none is chosen | 1 | 2 | 2 |
| Memory when none is chosen | 1 GB | 2 GB | 4 GB |
| Replicas, per service | 1 | 3 | 20 |
| Disk per replica, outside a volume | 2 GB | 10 GB | 40 GB |
| Processes per replica | 512 | 2,048 | 4,096 |
| Longest healthcheck wait | 2 min | 10 min | 30 min |
| Longest overlap during a rollout | 1 min | 2 min | 10 min |
| Longest cron run | 15 min | 1 h | 6 h |
| Replicas, workspace total | 5 | 30 | 200 |
| vCPU, workspace total | 5 | 48 | 256 |
| Memory, workspace total | 5 GBAbout 2 GB on the $5 credit | 96 GB | 512 GB |
| Memory you can always reserve | 2 GB | 4 GB | 8 GB |
| Volume storage | 1 GB | 50 GB | 250 GB |
| Encrypted backups to S3 | No | Yes | Yes |
| Backup storage | No | 20 GB | 100 GB |
| Variables in one service or environment | 256 KB | 256 KB | 256 KB |
| Variables in the workspace | 2 MB | 32 MB | 128 MB |
| Deployment records, variables and activity | 32 MB | 256 MB | 1 GB |
| Usage included | $5, once | $5 a month | $20 a month |
| Default spend limit | The credit | $20 | $100 |
| Highest spend limit | The credit | $200 | $2,000 |
| Team members | No plan limit | No plan limit | No plan limit |
| Regions | One region for now | One region for now | One region for now |
| Support | |||
| Uptime commitment | No SLA yet | No SLA yet | No SLA yet |
| Deploys per hour | 20 | 120 | 600 |
| Builds at once | 1 | 2 | 4 |
| Build servers | Shared pool | Your workspace’s own | Your workspace’s own |
| Longest build | 15 min | 30 min | 60 min |
| Build minutes per period | 120 | 1,000 | 6,000 |
| Each build gets | 1 vCPU, 2 GB | 2 vCPU, 4 GB | 4 vCPU, 8 GB |
| Build disk | 5 GB | 20 GB | 50 GB |
| Largest image | 3 GB | 10 GB | 25 GB |
| Largest source | 1 GB | 4 GB | 4 GB |
| Largest upload | 100 MB | 500 MB | 500 MB |
| Images kept on one server | 3 | 10 | 30 |
| Image storage on one server | 6 GB | 30 GB | 100 GB |
| Images and sources moved per hour | 10 GB | 100 GB | 400 GB |
| Deployments kept per service | Newest 100 | Newest 100 | Newest 100 |
| Uploads kept for redeploys | 2 GB | 10 GB | 50 GB |
| Generated domains per service | 2 | 5 | 10 |
| Custom domains per service | 1 | 2 | 20 |
| Custom domains in total | 3 | 30 | 300 |
| Wildcard domains | No | Yes | Yes |
| New certificates per week | 5 | 30 | 200 |
| Public TCP ports | 3 | 20 | 100 |
| Environments on one server | 4 | 20 | 100 |
| Traffic out per period | 50 GB | 2 TB | 20 TB |
| Outbound speed | 5 MB/s per server | 25 MB/s per container | 25 MB/s per container |
| New TCP connections a second | 20 per server | 100 per container500 per server | 100 per container2,000 per server |
| Open connections on one server | 2,000 | 20,000 | 100,000 |
| Mail submission ports | No | No | Yes |
| SSH, RDP and SMB ports, going out | Closed | 2 new connections a second | 2 new connections a second |
| Metrics history | 1 day | 7 days | 30 days |
| Build and deploy logs, kept for | 7 days | 14 days | 30 days |
| Build and deploy logs, total size | 0.5 GB | 5 GB | 20 GB |
| Activity log, kept for | 14 days | 30 days | 90 days |
| Activity log, total size | 4 MB | 16 MB | 64 MB |
The service limit is checked per environment when you create a service. Volume storage is the total size of all volumes in the workspace. Trial credit is given once per mailbox, on the personal workspace, to accounts with Google or GitHub behind them. GitHub accounts younger than 30 days don’t get the trial credit. It’s also limited each day, so on a very busy day a new account may start without it. Accounts made with an email and password don’t get it, and can buy credit or a plan in Settings → Billing. While online payments are closed, sign up with Google or GitHub: an account made with an email and password can’t deploy yet.
An action that would go over a limit fails with a message naming the limit and the plan, and a hint to upgrade under Settings → Plans.
Other limits you might meet
- Disk. A replica may keep 2 GB on Trial, 10 GB on Hobby and 40 GB on Pro outside a volume. Past that it’s stopped and you get a notification. Its files outside a volume are gone, and you can deploy again when you’re ready, so keep anything you need in a volume. If a whole server passes 90% full, cleanup runs first, then the biggest user’s biggest service is stopped the same way, counting a trial’s use double. Volumes are never touched.
- Old deployments and logs. Each service keeps its newest 100 deployments, and a workspace has room for 32 MB of deployment records, variables and activity on Trial, 256 MB on Hobby and 1 GB on Pro. Past either, the oldest finished deployments are removed, which can take old rollback targets with them. Build and deploy logs are kept for 7 days on Trial, 14 on Hobby and 30 on Pro, up to 0.5 GB, 5 GB and 20 GB in total. Images beyond what’s running may take 6 GB, 30 GB and 100 GB on each server, and old rollback targets give way first. The activity log keeps 14 days on Trial, 30 on Hobby and 90 on Pro, up to 4 MB, 16 MB and 64 MB. A running deployment always stays.
- Outbound connections. Port 25 is closed on every plan, and mail submission ports are open on Pro only. Trial apps can’t connect out to SSH, RDP or SMB ports (22, 23, 135, 139, 445, 3389 and 5900). On Hobby and Pro those ports take 2 new connections a second per container.
- The Dawnrose API. An app can’t reach the Dawnrose API or dashboard from inside its container. Call them from outside Dawnrose, such as your own servers or CI. To start a deploy from CI, you can also use the service’s deploy hook.
- Build servers. A paying workspace’s builds run on a server of its own, so a build can take a little longer to start while one is prepared. Trials share a separate pool.
Usage prices
| Resource | Price | Measured |
|---|---|---|
| CPU | $20 per vCPU per month | Per second, from actual use |
| Memory | $10 per GB per month | Per second, from actual use |
| Volumes and backups | $0.15 per GB per month | Hourly, from the space used on each volume and by stored backups |
| Egress | $0.05 per GB | Everything leaving your containers, direct connections and WebSockets included. Traffic between services on the same server isn’t billed. The plan’s cap on outbound data counts it the same way, except that on servers that don’t report workspace totals yet it also counts traffic between your own services. |
A month here is 30 days. A sleeping service has no running containers, so it uses no CPU or memory.
Billing periods and credits
Usage is counted per billing period: the plan’s month on Hobby and Pro, and 30 days on the Trial. On Hobby and Pro, the subscription covers usage up to the included amount, and usage beyond it is charged against your prepaid credits at the end of the period. We don’t charge your card for extra usage, so with no credit left a workspace stops, on paid plans too. On Trial, all usage comes from the trial credit.
The Usage page in the sidebar shows the usage so far this period by resource, a chart of daily cost and your quotas. Settings → Plans compares the plans, and upgrades you with Upgrade to Hobby or Upgrade to Pro; its Upgrade to Hobby and Upgrade to Pro buttons work once online payments open. Settings → Billing lists your transactions, and under Credits & limits you can buy credits with Add credits (from $5 to $1,000, once online payments open), open the Billing portal and set the spend limit. On a trial, the credit left is shown at the top right of every page and above your projects.
Agents can read the same figures with get_usage.
Spend limits
The spend limit caps the total usage of a period. Paid plans always have one: the workspace’s own limit, or the plan default if you leave the field empty, and never more than the plan’s highest limit. Set it under Credits & limits → Spend limit and click Save limit. Only workspace owners can change it.
The workspace gets a usage.warning notification at 50%, 75% and 90% of its budget for the period, and usage.limit when it reaches it.
What happens at the limit
When a Trial workspace has used its credit, or a paid workspace reaches its spend limit or runs out of credit past what its plan includes, the workspace is suspended:
- Running services are stopped.
- New deployments are refused, and stopped services do not wake on requests.
- The Usage and Settings → Billing pages show “Usage limit reached”.
Add credits, upgrade the plan or raise the spend limit to resume. Until online payments open, a trial that has used its credit can’t be topped up from the dashboard; write to support@dawnrose.ai. The workspace becomes active again within a few minutes. Stopped services then start on their next request, or when you restart or redeploy them.