Deploy and run production web apps.
No infrastructure to manage.
Connect your repository and Darwa detects the framework, writes the build and start commands, deploys to the regions you choose, and keeps the service healthy — then tells you what to change when the numbers move.
You push. Darwa works out the rest.
Other platforms ask you for a build command and a start command before they will deploy anything — and a wrong guess is a failed deploy. Darwa reads the repository first and shows you what it found.
Build Command: ______________ Start Command: ______________ Runtime: [ select ] Port: ______________ Instance type: [ select ] Region: [ select ]
Six answers before the first deploy, each one a chance to fail. Beginners guess; experienced teams copy them between services and drift apart over time.
Every field is pre-filled and editable. The detection is committed to your project, so a new service in the same repository starts from the same answers.
A linked GitHub, GitLab, or Bitbucket repository, a public Git URL, or a prebuilt Docker image. All three deploy the same way.
Each commit to the tracked branch builds and releases with zero downtime. Automatic deploys can be paused per branch.
Every release is kept with its build log, commit, and configuration. Restoring a previous one takes a single click.
Every pull request gets a URL and a verdict.
A preview is not just a link. Darwa builds the branch, runs checks against it, and posts the result back on the pull request.
One per pull request, isolated from production, with its own database copy.
Any long-lived branch can have a permanent environment of its own.
Build, performance against main, dependency advisories, and bundle size.
Environments and their data are destroyed on merge or close.
One service definition, every kind of process.
Web processes, workers, and scheduled jobs run from the same repository and the same release, so they can never drift out of sync.
Your process stays up. Crashes restart automatically, health checks gate traffic, and no instance ever sleeps — including on the free tier.
Run workers beside your web process from the same repository. Queues, consumers, and long jobs share the same release.
Schedule commands with a cron expression. Each run is a recorded execution with its own logs and exit status.
Long-lived connections and multiplexed requests are supported by default. No proxy configuration, no upgrade headers to tune.
Bind to PORT and you are done. If your app binds elsewhere, Darwa detects the listening port at build time instead of failing the deploy.
const port = process.env.PORT || 3000;
app.listen(port, "0.0.0.0", () => {
console.log(`listening on ${port}`);
});Variables are set per environment and diffed between them, so the classic “works in staging, missing in production” failure is caught before you deploy.
Scale before the traffic lands, not after.
Reactive autoscaling always arrives late — it waits for saturation, and your users feel the gap. Darwa reads the shape of your traffic and moves first.
More CPU and memory for a single instance, applied on a rolling restart with no dropped requests.
More instances behind the load balancer, added and removed automatically within limits you set.
Target CPU, memory, request rate, or queue depth — with hard minimums and maximums per environment.
The agent compares this week to the last and proposes a plan change only when the numbers justify it.
Public URL, your domain, and a private network.
Every service gets a darwa.app subdomain immediately. Add your own domain and the certificate is issued and renewed without you touching DNS twice.
Apex, subdomain, and wildcard support with a verification record you paste once.
Managed certificates issued on connect, renewed before expiry, HTTP redirected to HTTPS.
Load balancing across instances and regions, with the closest healthy region serving each request.
Assets cached at the edge with compression, so your process only serves what changes.
Mark a service private and it leaves the public internet entirely, reachable only by your other services.
Serve a holding page on demand while you migrate data, with health checks paused.
Monitoring that comes with the service.
Latency, errors, saturation, and uptime are part of the platform — not three third-party subscriptions you wire up after launch.
Build and runtime streams in one place, searchable, filterable by level and instance, downloadable as plain text.
Request latency, slow endpoints, error rate, memory growth, and CPU pressure — no agent to install, no separate bill.
A path you nominate is polled continuously. Failing instances leave rotation before users notice them.
Notify on error-rate spikes, saturation, failed deploys, and cron failures — to email, Slack, or a webhook.
One number per service, with the reason it is not 100 and the change that would fix it.
Usage, a monthly estimate, alerts before you cross a threshold, and the specific resize that saves money — with the projected effect on latency stated up front.
Logs tell you what happened. Darwa tells you why.
The assistant reads the build, the release, the logs, and the metrics together — so a stack trace becomes a cause, a fix, and a button.
Why the build broke, which file, and whether it is your code or a missing variable.
“Your service restarted 42 times because memory exceeded the limit — raise memory or fix this endpoint.”
Ranks endpoints by time lost, points at the query or call responsible.
Proposes instance and plan changes from real usage, never from a default.
If error rate jumps after a release, the previous version is restored and you get the reason.
Flags waits, missing indexes, and pool limits when your app is fast but the query is not.
Included, not an upsell.
The protections most teams bolt on after an incident ship with every web service.
| Protection | What it does | Included |
|---|---|---|
| HTTPS everywhere | Managed certificates, renewed automatically, HTTP redirected to HTTPS | All plans |
| Secrets management | Encrypted at rest, injected at runtime, never printed in build output | All plans |
| Dependency scanning | Every build checks your lockfile against known advisories | All plans |
| Exposed secret detection | Commits and images are scanned for keys before they ship | All plans |
| DDoS protection | Absorbed at the edge, with rate limiting per route | All plans |
| Private services | Reachable only from your own services, never from the public internet | All plans |
Shared services, scoped access, full history.
Roles decide who can deploy, who can approve, and who can only look.
Owner, maintainer, contributor, and viewer — applied per project, not per account.
Require one or two sign-offs before a release reaches production.
Every deploy, rollback, variable change, and access grant, with who and when.
Priced per service, with a free tier that stays awake.
No cold starts on free, no separate monitoring bill, and a usage estimate on every service before the invoice arrives.
For community projects and prototypes that still need to be awake.
- Always available — no cold starts
- 512 MB / shared CPU
- 1 region
- Preview environments
- Logs, metrics, health checks
- Community support
For small production services with real users.
- 512 MB – 1 GB, 0.5 vCPU
- 3 regions
- Custom domains + SSL
- Autoscaling to 3 instances
- Cost intelligence
- Email support
For teams running revenue-critical applications.
- Up to 8 vCPU / 32 GB
- All 15 regions
- Predictive autoscaling
- Full APM + health score
- AI diagnosis and auto-rollback
- Deployment approvals
- Priority support
For companies with compliance and capacity commitments.
- Dedicated capacity
- Private networking + peering
- SSO, audit logs, SOC 2
- Custom regions
- 99.99% SLA
- Named engineer
Point Darwa at a repository and watch it deploy.
No build commands, no instance sizing, no monitoring setup. Change your mind later — every detected setting is editable.