Coolify helps you deploy apps, databases, and services on infrastructure you bring. It is attractive when you want a self-hosted platform experience over your own servers.

W7S helps you deploy repository-shaped apps through GitHub Actions. It is attractive when you want static assets, native backends, storage, queues, schedules, workflows, branch environments, and app URLs without asking every project to manage servers.

The short version:

Choose Coolify when you want to operate your own servers. Choose W7S when you want GitHub-native app deployment and managed platform primitives.

Coolify vs W7S​

These tools are not interchangeable clones. They sit at different layers.

Source-Backed Comparison Points​

The Coolify side of this comparison is based on the live Coolify pricing page and Coolify docs for applications, services, and servers. Those pages back the article's claim that Coolify is organized around apps and services running on connected infrastructure.

The W7S side is based on Deploy From GitHub, Project Layouts, Storage Bindings, and URLs and Routing. Those pages back the claim that W7S starts from the repository and deploys app-shaped projects through GitHub Actions.

The self-hosting distinction is backed by Coolify's own pricing and server docs, plus Self Host W7S. Coolify self-hosting means running a control plane for infrastructure you bring. W7S self-hosting means running the W7S deployment cloud while app repositories keep the same GitHub-native deployment contract.

The backend-platform comparison is supported by W7S docs for Serverless Database, Backend Queues, Backend Schedules, Backend Workflows, and Backend RPC. Those primitives are why W7S can be a real alternative for app-shaped projects that do not need arbitrary containers.

The cost and operations claims use Coolify pricing, W7S pricing, and W7S Usage Accounting. The article links directly to those pages because server costs, platform prices, and included usage limits can change.

What Coolify Is Best At​

Coolify is strongest when the operating model starts with servers you control.

Its pricing page currently describes self-hosting as free forever on your own infrastructure, with full access to features and community support. It also lists Coolify Cloud as a managed Coolify control plane with a base monthly price for connected servers, plus a monthly price per additional server. The important detail is that you still bring the servers where apps run.

That makes Coolify a good fit for:

• VPS-based hosting;
• self-hosted apps;
• Docker and service deployments;
• databases you want to run yourself;
• homelab and agency workflows;
• teams that want a Heroku-like layer over machines they control;
• apps that need container/process flexibility.

Coolify is the better choice when server ownership is the goal.

What W7S Is Best At​

W7S is strongest when the operating model starts with a GitHub repository.

The app deploys from GitHub Actions:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v6
        with:
          node-version: 22
      - run: npm ci
      - run: npm run build
      - uses: w7s-io/w7s-cloud@v1
        with:
          token: ${{ github.token }}

The runtime contract lives in w7s.json:

{
  "bindings": {
    "db": [
      {
        "binding": "DB",
        "migrations": "migrations"
      }
    ],
    "kv": ["CACHE"],
    "fs": ["FILES"]
  },
  "queues": ["jobs"],
  "schedules": [
    {
      "cron": "0 * * * *",
      "path": "/_w7s/schedules/hourly"
    }
  ],
  "workflows": ["checkout"]
}

That makes W7S a better fit for:

• static sites that grow into apps;
• JavaScript and TypeScript native backends;
• repo-declared DB, KV, FS, queues, schedules, and workflows;
• branch environments;
• internal backend RPC by repository identity;
• GitHub-native usage warnings;
• teams that want a self-hostable platform path without making every app team manage servers.

W7S is the better choice when the repository should be the unit of deployment.

The Self-Hosting Difference​

Both products can be discussed as self-hostable, but the meaning is different.

With Coolify, self-hosting usually means:

• you run Coolify;
• you connect servers;
• your apps deploy to those servers;
• you manage server capacity, OS updates, Docker behavior, database backups, disks, network rules, and service health.

With W7S, self-hosting means:

• you run the W7S deployment cloud under your own domain and infrastructure account;
• app repositories still deploy through the W7S GitHub Action;
• apps still use owner/repo-derived URLs and branch environments;
• the platform continues to expose W7S primitives instead of turning every app into server management.

Coolify gives you a control panel for your servers. W7S gives you an app platform that can be hosted by you.

Runtime Shape Matters​

Coolify supports a broader class of workloads because it is closer to containers and services.

Use Coolify when the app needs:

• arbitrary containers;
• long-running processes;
• custom service topology;
• databases and services you want to run directly;
• shell/server-level access;
• private server networks;
• app stacks that do not fit W7S native backends.

W7S intentionally narrows the runtime:

• static assets;
• JavaScript or TypeScript backend handlers;
• DB, KV, FS, queues, schedules, workflows, Stateful Objects, and AI bindings;
• internal RPC;
• GitHub Actions deploys;
• branch environments.

That narrower model is a feature when the app fits it. It removes server choices from projects that do not need them.

Cost Model Difference​

Coolify's public pricing makes the infrastructure ownership clear. Self-hosted Coolify is free as software, but you need your own infrastructure. Coolify Cloud charges for the managed control plane while your apps still deploy to servers you bring.

W7S hosted deployment starts free without a W7S account, credit card, or separate cloud setup. When an app gets meaningful traffic, W7S is designed around usage-based cost for app primitives and platform overhead.

So the cost comparison is not just monthly subscription versus monthly subscription.

With Coolify, include:

• Coolify Cloud fee if using it;
• server rental;
• database/storage costs;
• backups;
• monitoring;
• time spent operating the machines.

With W7S, include:

• app usage;
• storage and backend primitive usage;
• platform overhead included in W7S estimates;
• whether the app outgrows the W7S runtime model.

When Coolify Is Better​

Choose Coolify when:

• you want to bring your own servers;
• you want to deploy arbitrary containers;
• you want to run databases and services yourself;
• you need process-level control;
• you are comfortable operating the server layer;
• your organization values server ownership over a narrower app platform.

Coolify is a strong choice for teams that already think in servers and services.

When W7S Is Better​

Choose W7S when:

• the app can be static assets plus native backend routes;
• GitHub Actions should own deploys;
• the deploy token should be the GitHub token;
• branch environments should be automatic and repo-scoped;
• DB, KV, FS, queues, schedules, workflows, vars, and secrets should be declared with the app;
• internal service calls should use repository identity;
• you do not want every project to size, patch, monitor, and back up servers;
• you want the option to self-host the platform later.

W7S is better when server management is not part of the product you are building.

Recommendation​

Do not ask "Coolify or W7S?" first. Ask what you want to own.

If you want to own servers and run a broad set of containers, choose Coolify.

If you want GitHub-native app deployment with a small set of managed primitives, choose W7S.

Both can be good tools. The wrong choice is picking server management when you wanted an app platform, or picking an app platform when the workload really needs server control.

Current Pricing Sources​

Pricing changes. Check the current public pages before making a final cost decision:

• Coolify pricing
• W7S pricing calculator

If you used Heroku as a simple process host, Render, Railway, Fly.io, Google Cloud Run, AWS App Runner, DigitalOcean App Platform, and Coolify are natural comparisons. If you used Heroku as a full application platform with dynos, add-ons, config vars, logs, and Git deploys, the decision is more subtle.

W7S is a Heroku alternative for a specific and common app shape:

Use W7S when the app can be static assets, native backend routes, managed bindings, queues, schedules, and workflows instead of always-on processes.

That makes W7S better for small and medium apps where the process was mostly packaging around request handlers, background jobs, storage, and a deploy workflow from GitHub.

The Short List​

Heroku is still useful. Its pricing page describes dynos as the heart of a Heroku app, with dyno tiers such as Eco, Basic, Standard, Performance, and larger private-space options. That is a process model: the app runs in isolated containers that handle code, dependencies, and scaling.

W7S competes by changing that model for apps that do not need a long-running process.

Source-Backed Comparison Points​

Heroku's runtime model is documented in its pages for dynos, the Procfile, config vars, add-ons, and one-off dynos. Those sources back the article's description of Heroku as a process-centered app platform.

The W7S replacement model is backed by the W7S docs for deploying from GitHub, project layouts, storage bindings, serverless database, and URLs and routing. Those pages show how a repository can own deployment, native backend shape, app URLs, and runtime bindings without a dyno layer.

The background-work comparison is based on the W7S docs for Backend Queues, Backend Schedules, and Backend Workflows. Those primitives are the reason W7S can replace worker dynos for common async jobs, scheduled syncs, webhook retries, and durable application processes.

Other Heroku alternatives still matter when an app is process-shaped. Render documents web services, background workers, and cron jobs; Fly.io documents Machines; Google documents Cloud Run; and AWS documents App Runner. Those sources back the article's recommendation to keep process platforms for process-shaped workloads.

The cost and ownership claims are tied to Heroku pricing, the W7S pricing calculator, W7S usage accounting, and self-hosting W7S. Pricing pages change, so the article points readers to the live sources instead of treating any single number as permanent.

What Heroku Gives You​

Heroku became popular because it gave developers a simple application surface:

• a Procfile;
• web and worker dynos;
• config vars;
• add-on databases and services;
• logs and metrics;
• Git-based deploys;
• scaling through dyno counts and dyno sizes;
• release commands and one-off tasks;
• custom domains and TLS.

That is a good shape when the application genuinely needs processes. A Rails app, Django app, Phoenix app, long-running worker, or containerized service can fit that model well.

The cost is that every app becomes something you operate as a set of services. You think about process types, process sizes, worker counts, add-ons, startup commands, health checks, deployment phases, and idle behavior.

For many modern JavaScript and TypeScript apps, that is heavier than necessary.

What W7S Replaces​

W7S maps the common Heroku platform pieces to repository-native components:

The point is not to clone Heroku. The point is to remove the process layer when the app does not need it.

From Procfile to Native Backend​

A Heroku app often starts with a Procfile:

web: npm start
worker: npm run worker

In W7S, the backend is a request handler:

export default {
  async fetch(request: Request, env: Env) {
    const url = new URL(request.url);

    if (url.pathname === "/api/health") {
      return Response.json({ok: true});
    }

    if (url.pathname === "/api/orders" && request.method === "POST") {
      return createOrder(request, env);
    }

    return new Response("Not found", {status: 404});
  }
};

There is no port to bind and no dyno size to choose. W7S owns request dispatch; the app owns the handler code.

That is a better fit when the backend is mostly HTTP routes, validation, auth, database access, file writes, and calls to other app components.

From Worker Dynos to Queues​

A Heroku worker dyno is a good abstraction when you have a long-running worker process.

Many apps only need async delivery. In W7S, the app declares a queue:

{
  "queues": [
    {
      "name": "jobs",
      "consumer": "/_w7s/queues/jobs"
    }
  ]
}

The backend consumes messages through a route:

if (url.pathname === "/_w7s/queues/jobs" && request.method === "POST") {
  const batch = await request.json();

  for (const message of batch.messages) {
    await sendReceipt(message.body, env);
  }

  return Response.json({ok: true, processed: batch.messages.length});
}

That removes a separate process for jobs that already belong to the app.

From Add-Ons to Bindings​

Heroku add-ons are convenient, but they often put the runtime contract across a dashboard, provider account, environment variables, and application code.

W7S puts common resources in w7s.json:

{
  "bindings": {
    "db": [
      {
        "binding": "DB",
        "migrations": "migrations"
      }
    ],
    "kv": ["CACHE"],
    "fs": ["FILES"]
  },
  "queues": ["jobs"],
  "schedules": [
    {
      "cron": "0 * * * *",
      "path": "/_w7s/schedules/hourly"
    }
  ],
  "vars": ["PUBLIC_APP_ORIGIN"],
  "secrets": ["STRIPE_SECRET_KEY"]
}

The repository explains what the app needs. Branch environments can get isolated resources without copying dashboard settings by hand.

Why W7S Can Be Better Than Heroku​

W7S is better than Heroku when these priorities matter more than process control:

• deploy behavior should be reviewable in .github/workflows/deploy.yml;
• the deploy token should be the GitHub token;
• static frontend and backend routes should ship together;
• storage and jobs should be declared with the app;
• branch previews should include backend and storage behavior;
• internal backend calls should use repository identity;
• cost should follow usage instead of an always-on process baseline;
• the platform should have an open-source and self-hostable path.

For a solo builder or small team, the biggest difference is not a feature checklist. It is the number of operational decisions removed from each repo.

When Heroku or a Process Platform Still Wins​

Do not replace Heroku with W7S if the app needs:

• arbitrary containers;
• non-JavaScript runtimes as the main app server;
• long-running daemon processes;
• custom TCP listeners;
• process-level WebSocket control;
• private networking between long-running services;
• shell access into running app containers;
• mature Heroku add-ons your team depends on;
• a Heroku-specific workflow already standardized across the organization.

Render, Railway, Fly.io, Cloud Run, App Runner, DigitalOcean App Platform, Kubernetes, or Coolify may be better if the workload is truly process-shaped.

Recommendation​

Start with the runtime shape.

Use W7S when the app is mostly:

• static assets;
• JavaScript or TypeScript request handlers;
• serverless DB, KV, FS, queues, schedules, workflows, and Stateful Objects;
• GitHub Actions deploys;
• branch environments;
• repo-owned runtime configuration.

Use Heroku or a Heroku-like process platform when the app really needs always-on processes.

The mistake is not choosing Heroku. The mistake is keeping a process platform just because the app used to need one.

Current Pricing Sources​

Pricing changes. Check the current public pages before making a final cost decision:

• Heroku pricing
• W7S pricing calculator

Netlify is strong when you want a polished hosted workflow for frontend projects: Git-connected deploys, branch previews, functions, edge features, forms, a dashboard, team collaboration, analytics, and a growing set of platform services.

W7S is different:

W7S is the Netlify alternative for teams that want GitHub Actions and the repository to own the deployment contract.

That makes W7S better when the site has become an app and the app needs backend routes, storage, queues, schedules, workflows, internal service calls, and predictable branch environments without moving the source of truth into a dashboard.

Netlify vs W7S​

Netlify remains a good fit when the dashboard workflow, visual collaboration, forms product, plugins, and frontend platform surface are central to the team.

W7S is better when those features are less important than keeping deploys, runtime shape, and app resources visible in the repository.

Source-Backed Comparison Points​

Netlify's frontend platform strengths are documented in its pages for Deploy Previews, Functions, Edge Functions, Forms, and Scheduled Functions. Those sources back the article's claim that Netlify remains a strong frontend workflow product.

The W7S deployment comparison is backed by Deploy From GitHub, Project Layouts, and URLs and Routing. Those pages show how build and deploy behavior can live in GitHub Actions while the app receives predictable owner/repo and branch URLs.

The backend comparison is backed by Storage Bindings, Serverless Database, Backend Queues, Backend Schedules, Backend Workflows, and Backend RPC. Those W7S docs are the reason this article describes W7S as an app platform alternative rather than just another static site host.

The preview-environment claim is supported by the combination of Netlify's Deploy Preview model and W7S docs for URLs and Routing plus Storage Bindings. Netlify proves the value of branch previews; W7S extends that idea to branch-scoped runtime behavior for apps that need backend resources.

The pricing and ownership claims use Netlify pricing, W7S pricing, Usage Accounting, and Self Host W7S. These links are included because pricing and platform limits change over time.

Why Teams Look for a Netlify Alternative​

Teams usually start looking beyond Netlify for one of five reasons:

1. The site needs more backend behavior than a few isolated functions.
2. Storage and background jobs are becoming part of the product.
3. The team wants build and deploy behavior reviewed in pull requests.
4. Pricing needs to map more directly to app usage.
5. The app should have a self-hostable or open-source platform path.

These are not Netlify failures. They are signs that a static site has become an application.

W7S is built for that moment.

Deploy From GitHub Actions​

Netlify's default workflow is to connect a repository to a Netlify project. That project builds and deploys pushes and previews.

W7S moves the release logic into GitHub Actions:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v6
        with:
          node-version: 22
      - run: npm ci
      - run: npm run build
      - uses: w7s-io/w7s-cloud@v1
        with:
          token: ${{ github.token }}

The workflow can run tests, generate assets, build multiple packages, run migrations, package a specific directory, and deploy only after the checks you choose.

The practical win is reviewability. If the deploy command changes, the pull request shows it.

Replace Functions With a Native Backend​

File-per-function routing is convenient at first. It gets less convenient when the app needs shared auth, validation, error handling, logging, database helpers, queue helpers, and internal RPC.

W7S uses a native backend:

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const url = new URL(request.url);

    if (url.pathname === "/api/health") {
      return Response.json({ok: true});
    }

    if (url.pathname === "/api/contact" && request.method === "POST") {
      return submitContactForm(request, env);
    }

    if (url.pathname === "/api/orders" && request.method === "POST") {
      return createOrder(request, env, ctx);
    }

    return new Response("Not found", {status: 404});
  }
};

You can still keep route modules if you want. The difference is that the backend is one service-shaped entrypoint instead of a platform-specific folder convention.

Replace Forms With App Code​

Netlify Forms are useful for simple marketing and contact flows.

W7S does not try to clone that product feature. It gives you the primitives to implement the flow in application code:

• validate the submitted body in a backend route;
• write the record to DB or KV;
• store files in FS;
• enqueue notification work;
• start a workflow when the form needs approval or retries;
• keep spam filtering and business logic in code.

That is better when the form is not just a form anymore. Lead routing, account creation, checkout, waitlists, uploads, support intake, and moderation queues usually become app behavior.

Declare Storage and Jobs With the App​

A Netlify project can use environment variables, functions, build plugins, and external services. W7S pushes the app runtime contract into one manifest:

{
  "bindings": {
    "db": [
      {
        "binding": "DB",
        "migrations": "migrations"
      }
    ],
    "kv": ["CACHE"],
    "fs": ["FILES"]
  },
  "queues": [
    {
      "name": "mail",
      "consumer": "/_w7s/queues/mail"
    }
  ],
  "schedules": [
    {
      "cron": "*/15 * * * *",
      "path": "/_w7s/schedules/sync"
    }
  ],
  "workflows": ["checkout"],
  "vars": ["PUBLIC_APP_ORIGIN"],
  "secrets": ["RESEND_API_KEY"]
}

That makes the repository the document for how the app runs.

Branch Environments Are More Than Previews​

Preview deploys are useful because reviewers can open the branch.

Branch environments are more useful because the branch can test runtime behavior:

• backend routes;
• database migrations;
• KV and FS usage;
• queues and schedules;
• internal RPC;
• workflows;
• vars and secrets scoped to the environment.

W7S turns branch names into environment names and derives predictable URLs from the GitHub owner and repository. A review app can be more than a rendered frontend.

Pricing Model Difference​

Netlify's current public pricing is credit-based. Its pricing page lists a Free plan with a monthly credit limit, Personal and Pro monthly plans, Enterprise custom pricing, and credit usage for production deploys, compute, bandwidth, web requests, and other platform work.

W7S is free to start on w7s.cloud without a W7S account, credit card, or separate cloud setup. The hosted service is designed so small apps can deploy, test, demo, and share before billing matters. When apps get meaningful traffic, the W7S model is intended to be usage-based instead of a mandatory subscription just to keep an app online.

The difference is not only price. It is what gets priced. W7S tries to keep the pricing conversation aligned with app primitives: runtime requests, CPU, storage, DB rows, queues, stateful work, logs, and W7S platform overhead.

When Netlify Still Wins​

Keep Netlify when you need:

• Netlify Forms as a product feature;
• Netlify's dashboard and team workflow;
• visual collaboration and preview tooling;
• plugins and extensions your build depends on;
• Netlify-specific edge or function behavior;
• organization policy already built around Netlify;
• a mature frontend platform with less custom CI setup.

Use W7S when the repository should own the deployment and the app can fit W7S's runtime model.

Recommendation​

Choose W7S as a Netlify alternative when the project can be described as:

• static assets built in GitHub Actions;
• JavaScript or TypeScript backend routes;
• repo-declared DB, KV, FS, queues, schedules, workflows, vars, and secrets;
• branch environments for runtime previews;
• GitHub as the release control plane.

Choose Netlify when its hosted frontend product is the workflow you want.

The practical question is simple: should this app be managed from a dashboard, or should the repository explain how it deploys and runs?

Current Pricing Sources​

Pricing changes. Check the current public pages before making a final cost decision:

• Netlify pricing
• W7S pricing calculator

That power is also the reason teams end up rebuilding the same product workflow:

• how should repositories deploy?
• where do bindings live?
• how should branch environments be named?
• how should URLs be derived?
• how should one app call another?
• how are storage resources named and reused?
• which settings live in the dashboard, Wrangler config, Terraform, or CI?

W7S is built on a focused subset of these primitives. It does not replace Cloudflare Workers as the underlying runtime. It replaces the repeated app-platform layer many teams build on top.

The Short Mapping​

Source-Backed Comparison Points​

Cloudflare's own docs describe Workers as a serverless execution environment and Pages as a full-stack deployment product. That is a strong foundation, but it still leaves each team deciding how repositories, deploy credentials, preview branches, routes, and runtime configuration should be standardized across many apps.

The same Cloudflare documentation set also exposes the breadth of the primitive layer: KV for key-value data, R2 for object storage, D1 for serverless SQL, Queues for async delivery, and Workflows for durable multi-step work. W7S is compelling precisely because it narrows that surface into a repository contract instead of asking every small app to assemble the same menu again.

In W7S, deploying from GitHub is the primary release path. The CI workflow builds the app, the W7S action sends the archive, and the platform derives identity from the GitHub owner, repository, branch, and commit. That makes the deploy mechanism reviewable in code, which is harder to preserve when the important project state is split between Wrangler config, dashboard settings, manually named resources, and external automation.

The runtime shape is also documented in W7S instead of being left to convention. Project layouts explain how static output and native backend entrypoints are discovered, while storage bindings define how databases, key-value stores, and file buckets are declared. This is where W7S becomes more than a thin deploy wrapper: it gives small apps a standard way to ask for platform resources.

The practical conclusion is not that teams should avoid Cloudflare. W7S depends on the same class of edge primitives and can also be self-hosted when a team wants its own domain and Cloudflare account boundary. The difference is product shape: raw Cloudflare gives maximum primitive control, while W7S gives a repeatable app-platform workflow for repositories that should not need bespoke infrastructure design.

The goal is not less Cloudflare. The goal is less repeated platform glue.

W7S Is a Product Workflow on Top of Primitives​

With raw Workers, you decide how to wire the project:

name = "api"
main = "src/index.ts"
compatibility_date = "2026-05-31"

[[kv_namespaces]]
binding = "CACHE"
id = "..."

[[d1_databases]]
binding = "DB"
database_name = "api-db"
database_id = "..."

That is appropriate when the team wants direct Cloudflare control.

W7S chooses conventions for you:

{
  "bindings": {
    "kv": ["CACHE"],
    "db": [
      {
        "binding": "DB",
        "migrations": "migrations"
      }
    ]
  }
}

The app declares intent. W7S maps that intent to platform resources using repository and environment identity.

This is the product stance: an app should not need to invent its own naming, routing, deployment, and authorization system before it can store data and serve requests.

Deploys Move From Local CLI to GitHub Actions​

Raw Workers often start with local CLI deploys:

npx wrangler deploy

That is good for direct control. W7S makes GitHub Actions the default release boundary:

- uses: actions/checkout@v5
- uses: actions/setup-node@v6
  with:
    node-version: 22
- run: npm ci
- run: npm run build
- uses: w7s-io/w7s-cloud@v1
  with:
    token: ${{ github.token }}

The deploy token is the GitHub token. The archive comes from CI. The platform verifies repository identity and publishes the app.

That makes deploys reviewable, repeatable, and easy to copy across repositories.

Worker Names Become Repository Names​

Raw Workers need names, routes, domains, and environment conventions. Different teams choose different patterns.

W7S derives the default app identity from GitHub:

github.com/acme/docs -> https://acme.w7s.cloud/docs/
github.com/acme/api  -> https://acme.w7s.cloud/api/

Branch environments get branch-prefixed hosts. Custom domains can be declared in a CNAME file and authorized through DNS.

That convention is not as flexible as direct Cloudflare routing, but it removes decisions most small apps do not need to make.

Service Bindings Become Backend RPC​

Cloudflare service bindings are a strong primitive for Worker-to-Worker calls. The raw setup still leaves teams to decide naming, authorization, and environment routing.

W7S wraps the common app-level case as Backend RPC:

const response = await env.W7S_RPC.fetch(
  "https://w7s.internal/api/v1/rpc/acme/auth/session",
  {
    headers: {
      authorization: `Bearer ${env.W7S_RPC_TOKEN}`,
      cookie: request.headers.get("cookie") ?? ""
    }
  }
);

W7S resolves the caller from the deployment token, checks target authorization, dispatches to the matching environment, and injects caller identity headers.

Use raw service bindings when you need Cloudflare-specific binding control. Use W7S RPC when repositories are the service boundary.

Bindings Stay in One Manifest​

Raw Workers can use many Cloudflare resources, but each one has its own provisioning and configuration details.

W7S narrows the app-facing contract:

{
  "bindings": {
    "db": [{ "binding": "DB", "migrations": "migrations" }],
    "kv": ["CACHE"],
    "fs": ["FILES"],
    "durableObjects": [
      {
        "binding": "COUNTER",
        "className": "Counter"
      }
    ]
  },
  "queues": ["jobs"],
  "workflows": ["process-order"]
}

This lets a reviewer understand the runtime surface from one file:

• data;
• files;
• stateful objects;
• background jobs;
• durable workflows;
• runtime values.

The platform can still use Cloudflare under the hood. The app does not have to expose every underlying configuration choice.

Branch Environments Become a First-Class Convention​

Cloudflare can support multiple environments, preview deployments, Workers Builds, and many configuration shapes. The flexibility is useful, but teams often need conventions around what "staging" or "preview" means.

W7S chooses:

• production comes from main or master;
• branches become environment names;
• environment identity is injected into the backend;
• resources are scoped by owner, repo, environment, type, and binding name.

That makes a branch deploy feel like a real app, not just a script with a different name.

What Raw Cloudflare Still Does Better​

Use raw Cloudflare Workers, Pages, Wrangler, Terraform, or Pulumi when you need:

• full control over Cloudflare account resources;
• advanced routing and zone configuration;
• compatibility flags and low-level runtime settings not surfaced by W7S;
• non-W7S deployment flows;
• custom Workers for Platforms behavior;
• exact Cloudflare product feature access on day one;
• direct operations through Cloudflare's dashboard, API, or IaC tools;
• architectures that are not repository-app shaped.

W7S intentionally gives up breadth to provide a smaller product workflow.

Recommendation​

Use W7S when the repeated questions are more expensive than the platform choices:

• where do deploys live?
• how are app URLs named?
• how are bindings declared?
• how do branch environments work?
• how does one backend call another?
• how are queues and workflows wired?

Use raw Cloudflare when the application needs direct infrastructure control.

W7S is not an alternative to Cloudflare as infrastructure. It is an alternative to every team rebuilding a small app platform from Cloudflare primitives.

W7S starts from a different premise. If the application already deploys through W7S, the platform can own many of those concerns directly: deployment identity, internal routing, managed bindings, storage provisioning, background delivery, workflow dispatch, local multi-repo testing, and usage accounting.

That makes the useful question narrower than "can W7S run Dapr?"

Can the product behavior people reach for Dapr to get be built from W7S components that already exist?

For many W7S apps, yes.

The Short Mapping​

Source-Backed Comparison Points​

Dapr's current docs describe it as a runtime built around a sidecar architecture and distributed application building blocks. That is the right abstraction when a team needs one API surface across different languages, hosts, and infrastructure providers. It is also a meaningful operational choice: every app now depends on the sidecar lifecycle, component configuration, ports, and runtime behavior.

The most common Dapr building blocks map to product behaviors W7S already tries to provide inside the platform. Dapr service invocation becomes Backend RPC when W7S apps call each other by repository identity. Dapr publish and subscribe becomes explicit event fanout over backend queues when the subscribers are known W7S apps.

State is another place where W7S narrows the problem. Dapr has a broad state management abstraction because it must support many backing stores. W7S instead lets a repository declare app-local data through storage bindings, serverless database, key-value storage, or file storage, with environment-specific provisioning handled by the platform.

Dapr actors and workflow are powerful when the application needs virtual actor semantics or durable orchestration across services. W7S should not pretend to be a drop-in implementation of those APIs. The W7S-native path is stateful objects for per-key state and backend workflows for retryable business processes that fit the platform runtime.

That framing keeps the article honest. Dapr remains the better fit for heterogeneous fleets that require its exact API, sidecar model, or portability promise. W7S is the better fit when the app already lives in W7S and the team wants fewer moving parts: repository identity, internal RPC, queues, storage, workflows, local testing with w7s-local, and usage accounting from one deployment surface.

This is not a claim that W7S is a drop-in Dapr runtime. Dapr is built to be portable across hosts, languages, and infrastructure providers. W7S is built to make a GitHub repository deploy as an app with first-class platform bindings.

If the app needs Dapr's exact API surface, Dapr can remain an external dependency. If the app is using Dapr mostly to avoid rebuilding common distributed app plumbing, W7S can usually provide a smaller default.

Sidecars Become Platform Bindings​

Dapr puts a runtime process next to each service. The application talks to that sidecar over HTTP or gRPC, and the sidecar handles service discovery, component calls, state stores, pub/sub brokers, secret stores, and other building blocks.

That is valuable when the hosting platform is not opinionated enough to provide those pieces consistently. It also has costs:

• every service needs a sidecar process;
• local development needs Dapr initialization and component config;
• production needs sidecar lifecycle, ports, health checks, and resource limits;
• the app now depends on another runtime contract beside the host.

In W7S, the deployment platform already knows the repository, owner, branch environment, runtime, and declared resources. For JavaScript/TypeScript native backends, W7S injects bindings directly into env:

W7S_RPC
W7S_QUEUE
W7S_WORKFLOW
W7S_AI
W7S_OWNER
W7S_REPO
W7S_REPOSITORY
W7S_ENVIRONMENT

App-declared storage bindings such as DB, KV, and FS are also exposed on env. The backend calls the binding directly rather than sending every operation through a local sidecar.

That is the core tradeoff. Dapr standardizes through a sidecar API. W7S standardizes through repository deployment metadata and platform bindings.

App Identity Becomes Repository Identity​

Dapr service invocation depends on app IDs. W7S already has a stable app identity: the GitHub owner and repository, plus the deployment environment.

For example:

github.com/acme/auth
github.com/acme/checkout

become W7S repositories:

acme/auth
acme/checkout

Production deploys call production targets. Branch deploys call matching branch environments when those targets exist. Same-owner calls are allowed by default, while cross-owner calls stay target-controlled through allowlists.

This removes a separate service naming layer. The repo is the service boundary.

Service Invocation Becomes Backend RPC​

Dapr service invocation often looks like this:

const response = await fetch(
  "http://localhost:3500/v1.0/invoke/auth/method/session",
  {
    headers: {
      cookie: request.headers.get("cookie") ?? ""
    }
  }
);

The application calls the local sidecar, and the sidecar routes to the service named auth.

In W7S, a backend calls the target repository through W7S_RPC:

type Env = {
  W7S_RPC: Fetcher;
  W7S_RPC_TOKEN: string;
};

export async function getSession(request: Request, env: Env) {
  const response = await env.W7S_RPC.fetch(
    "https://w7s.internal/api/v1/rpc/acme/auth/session",
    {
      headers: {
        authorization: `Bearer ${env.W7S_RPC_TOKEN}`,
        cookie: request.headers.get("cookie") ?? ""
      }
    }
  );

  if (!response.ok) {
    throw new Error("Auth service unavailable");
  }

  return response.json();
}

The target backend receives a normal HTTP request at /session. W7S resolves the caller from the deployment token, checks authorization, dispatches to the target in the same environment, and injects caller identity headers.

Use RPC when the caller needs a response before it can finish its own request.

Pub/Sub Becomes Explicit Event Fanout​

Dapr pub/sub gives an app a stable publish API while the underlying broker can be Redis, Kafka, Azure Service Bus, NATS, RabbitMQ, or another component.

That abstraction is useful when broker portability is the primary goal. In W7S, the better default is often explicit app-level fanout:

1. a publisher calls an event-router backend through RPC;
2. the router validates the subject and publisher;
3. the router looks up subscribers from repo metadata or app config;
4. the router enqueues one queue message per subscriber;
5. each subscriber consumes its own W7S queue.

The queue consumer declares its queue in w7s.json:

{
  "queues": [
    {
      "name": "events",
      "consumer": "/_w7s/queues/events"
    }
  ]
}

The router sends to the subscriber through W7S_QUEUE:

type Env = {
  W7S_QUEUE: Fetcher;
  W7S_QUEUE_TOKEN: string;
};

export async function deliver(env: Env, event: unknown) {
  return env.W7S_QUEUE.fetch(
    "https://w7s.internal/api/v1/queues/acme/email-worker/events",
    {
      method: "POST",
      headers: {
        authorization: `Bearer ${env.W7S_QUEUE_TOKEN}`,
        "content-type": "application/json"
      },
      body: JSON.stringify(event)
    }
  );
}

The consumer receives a queue batch:

export default {
  async fetch(request: Request) {
    const url = new URL(request.url);

    if (url.pathname === "/_w7s/queues/events" && request.method === "POST") {
      const batch = await request.json();

      for (const message of batch.messages) {
        console.log("event", message.body);
      }

      return Response.json({ok: true, processed: batch.messages.length});
    }

    return new Response("Not found", {status: 404});
  }
};

This is less dynamic than Dapr broker-backed topics, but it keeps topology visible in repositories and W7S metadata. For many product systems, that is an advantage.

The runnable local version of this pattern is in examples/w7s-local-native-events.

State Stores Become App-Owned Storage​

Dapr state management gives apps a key/value API over a configured state store. That is a useful portable floor, especially when many services need the same API across hosts.

W7S has a different storage model: declare the storage the app actually needs, then read the binding directly from the backend.

{
  "bindings": {
    "kv": ["CACHE"],
    "fs": ["FILES"],
    "db": [
      {
        "binding": "DB",
        "migrations": "migrations"
      }
    ]
  }
}

Use the narrowest storage primitive that matches the data:

For relational app state, keep migrations in the repo:

CREATE TABLE IF NOT EXISTS orders (
  id TEXT PRIMARY KEY,
  email TEXT NOT NULL,
  amount INTEGER NOT NULL,
  created_at TEXT NOT NULL
);

Then query through env.DB:

type Env = {
  DB: D1Database;
};

export async function saveOrder(env: Env, order: Order) {
  await env.DB.prepare(
    "insert into orders (id, email, amount, created_at) values (?, ?, ?, ?)"
  )
    .bind(order.id, order.email, order.amount, new Date().toISOString())
    .run();
}

This gives up Dapr's common state API, but it gives the app a clearer data model and a deployment-owned migration path.

Bindings Become Specific W7S Bindings​

Dapr bindings provide a common way to call external systems and receive events from them. W7S should not reproduce that as a single generic binding layer unless the platform genuinely needs it.

The W7S default is more direct:

• queues for background work;
• schedules for cron-style triggers;
• workflows for durable processes;
• FS for files;
• DB and KV for data;
• AI bindings for model calls;
• runtime vars and secrets for provider credentials;
• normal fetch for external HTTP APIs.

For a time-based trigger, declare a schedule:

{
  "schedules": [
    {
      "cron": "*/5 * * * *",
      "path": "/_w7s/schedules/sync"
    }
  ]
}

Handle it as a backend route:

export default {
  async fetch(request: Request, env: Env) {
    const url = new URL(request.url);

    if (url.pathname === "/_w7s/schedules/sync") {
      await syncExternalSystem(env);
      return Response.json({ok: true});
    }

    return new Response("Not found", {status: 404});
  }
};

That keeps the trigger contract in the repository instead of hiding it behind a generic component file.

Actors Become Stateful Objects​

Dapr actors provide a virtual actor model: each actor has identity, state, single-threaded execution, activation, deactivation, timers, and reminders.

W7S Stateful Objects cover the most common app need behind that model: route all operations for one logical entity to one durable object with attached state.

Declare the object class:

{
  "bindings": {
    "durableObjects": [
      {
        "binding": "CART",
        "className": "Cart"
      }
    ]
  }
}

Implement the object:

export class Cart {
  constructor(ctx) {
    this.ctx = ctx;
  }

  async fetch(request) {
    const url = new URL(request.url);
    const items = (await this.ctx.storage.get("items")) ?? [];

    if (url.pathname === "/add" && request.method === "POST") {
      const item = await request.json();
      const next = [...items, item];
      await this.ctx.storage.put("items", next);
      return Response.json({items: next});
    }

    return Response.json({items});
  }
}

export default {
  fetch(request, env) {
    const cartId = new URL(request.url).searchParams.get("cart") ?? "default";
    const id = env.CART.idFromName(cartId);
    return env.CART.get(id).fetch(request);
  }
};

This is not a full clone of Dapr actors. If the application depends on actor reminders, placement behavior, or Dapr actor SDK semantics, keep Dapr or build those semantics explicitly. If the application needs durable per-key compute and state, Stateful Objects are the W7S-native fit.

Workflows Stay Workflows​

Dapr workflows are for long-running, fault-tolerant, stateful processes. W7S Workflows target the same product need: start a named process, persist the instance, dispatch work to the app, retry failures, and expose status.

Declare a workflow:

{
  "workflows": [
    {
      "name": "checkout",
      "path": "/_w7s/workflows/checkout"
    }
  ]
}

Start it through the platform binding:

type Env = {
  W7S_WORKFLOW: Fetcher;
  W7S_WORKFLOW_TOKEN: string;
};

export async function startCheckout(env: Env, orderId: string) {
  return env.W7S_WORKFLOW.fetch(
    "https://w7s.internal/api/v1/workflows/acme/checkout/checkout",
    {
      method: "POST",
      headers: {
        authorization: `Bearer ${env.W7S_WORKFLOW_TOKEN}`,
        "content-type": "application/json",
        "x-w7s-workflow-instance-id": orderId
      },
      body: JSON.stringify({orderId})
    }
  );
}

The app receives the workflow run at the configured path:

if (url.pathname === "/_w7s/workflows/checkout" && request.method === "POST") {
  const run = await request.json();
  await processCheckout(run.payload.orderId);
  return Response.json({ok: true});
}

W7S Workflows deliberately keep the app API small. The platform owns the workflow runner; the app owns the business step.

Secrets and Configuration Stay in the Deploy Contract​

Dapr can read secrets and configuration through component APIs. W7S keeps these concerns closer to GitHub and the deployment manifest.

Declare the values the backend expects:

{
  "vars": ["PUBLIC_STRIPE_KEY"],
  "secrets": ["STRIPE_SECRET_KEY"]
}

Pass them from GitHub Actions:

- uses: w7s-io/w7s-cloud@v1
  env:
    PUBLIC_STRIPE_KEY: ${{ vars.PUBLIC_STRIPE_KEY }}
    STRIPE_SECRET_KEY: ${{ secrets.STRIPE_SECRET_KEY }}
  with:
    token: ${{ github.token }}

Read them from env in the backend:

type Env = {
  PUBLIC_STRIPE_KEY: string;
  STRIPE_SECRET_KEY: string;
};

For dynamic app configuration, use app-owned storage:

• KV for simple flags and values;
• DB for configuration that needs audit, ownership, or query filters;
• FS for larger config documents.

That separates deploy-time secrets from runtime product configuration.

Resiliency Is Attached to the Primitive​

Dapr has a resiliency model that can apply retries, timeouts, and circuit breakers around building block calls. That is useful in a general distributed runtime.

In W7S, resiliency should usually be attached to the primitive that needs it:

• queues retry background delivery;
• workflows retry durable process steps;
• schedules retry by creating the next scheduled attempt;
• RPC callers use explicit timeout and retry helpers where the product can tolerate repeat calls;
• database writes use normal transaction and idempotency patterns.

A simple RPC helper can make retry behavior visible:

export async function callWithTimeout(
  fetcher: Fetcher,
  url: string,
  init: RequestInit,
  timeoutMs = 3000
) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);

  try {
    return await fetcher.fetch(url, {
      ...init,
      signal: controller.signal
    });
  } finally {
    clearTimeout(timer);
  }
}

Do not hide every failure behind a global policy. Some operations are safe to retry, some need idempotency keys, and some should fail fast.

Observability Becomes Repo-Scoped Logs and Usage​

Dapr gives a consistent runtime surface for metrics, tracing, and sidecar diagnostics. W7S can provide the platform part from deployment identity:

• logs are associated with repository and environment;
• RPC, queue, workflow, schedule, deploy, and runtime usage can be counted per app;
• the GitHub Action can report deploy summaries and usage warnings;
• branch environments can be inspected separately from production.

This is a different observability boundary. Dapr observes a distributed runtime. W7S observes repository deployments and platform-managed dispatch.

Apps can still emit structured logs and external telemetry where they need deeper product traces.

Local Development Without Dapr​

Dapr's local runtime is one of its strongest developer conveniences. W7S needs a local story too, but it should match the W7S deployment model.

Use w7s-local for repo-shaped routing:

w7s-local \
  --owner acme \
  --repo checkout \
  --port 8790 \
  --command "npm run dev" \
  --backend http://127.0.0.1:5173

For multi-repo tests, run one local W7S router per repo and put platform calls behind small helpers:

• hosted W7S calls env.W7S_RPC, env.W7S_QUEUE, or env.W7S_WORKFLOW;
• local development calls the target repo's w7s-local URL or a service double.

That keeps local tests honest about repository boundaries without requiring every developer to run a sidecar runtime and component stack.

What W7S Still Does Not Replace​

There are Dapr capabilities W7S should not pretend to replace today:

• a language-agnostic sidecar API for any host;
• Dapr's exact HTTP and gRPC API contracts;
• broker and state-store portability through Dapr component specs;
• Dapr actor SDK semantics, placement, timers, and reminders;
• Dapr's component ecosystem for many external services;
• Kubernetes-native Dapr operator behavior;
• Dapr resiliency policy resources;
• Dapr mTLS and sidecar-to-sidecar service mesh behavior.

If a team is standardizing across Kubernetes, VMs, edge nodes, local containers, and multiple languages, Dapr may still be the right abstraction. W7S compatibility should then mean making it easy to call external Dapr-enabled services, not pretending W7S is the Dapr runtime.

A W7S-Native Distributed App Layer​

The W7S direction should be smaller than reimplementing Dapr.

The most useful next layer is a W7S-native distributed app contract built from existing pieces:

{
  "services": {
    "call": ["acme/auth", "acme/billing"]
  },
  "events": {
    "publish": ["orders.created"],
    "subscribe": [
      {
        "subject": "orders.created",
        "queue": "events"
      }
    ]
  },
  "queues": ["events"],
  "workflows": ["checkout"],
  "bindings": {
    "db": [{ "binding": "DB", "migrations": "migrations" }],
    "kv": ["CACHE"]
  }
}

Under the hood, W7S can reuse deployment metadata, managed bindings, queue delivery, workflow dispatch, per-repo authorization, branch environment isolation, and usage accounting.

That gives W7S much of the ergonomics people want from Dapr without adding a sidecar runtime as a required platform dependency.

Recommendation​

Do not add Dapr as a required W7S dependency.

Use W7S-native primitives first:

• Backend RPC for synchronous service invocation;
• queues and an event router for async fanout;
• Serverless DB, KV, FS, and Stateful Objects for state;
• schedules for time-based triggers;
• workflows for durable business processes;
• w7s.json, vars, and secrets for the runtime contract;
• w7s-local for multi-repo development.

Keep Dapr for applications that truly need Dapr's sidecar API, component ecosystem, actor runtime, or cross-host portability. For W7S-native apps, the simpler path is to let W7S be the platform instead of adding another distributed runtime beside it.

For many docs sites, personal sites, and project pages, that is exactly enough.

W7S is for the moment after "static is enough" stops being true:

• the docs site needs a search endpoint;
• the landing page needs a form handler;
• the project page needs a status API;
• the app needs a database, file bucket, queue, schedule, or backend route;
• branch previews need isolated runtime resources.

GitHub Pages is static hosting. W7S is repository-native app hosting.

The Short Mapping​

Source-Backed Comparison Points​

GitHub's own Pages documentation makes the core boundary clear: GitHub Pages is a publishing feature for websites from a repository. That is ideal for docs, project pages, and static marketing sites. It is also the reason the article should not frame Pages as weak; it is excellent at the static publishing job it was designed to do.

The W7S argument starts when the repository needs more than static files. W7S keeps the release path in GitHub through deploys from GitHub Actions, but it can package a static frontend and native backend from the same repo. The project layout docs are the important source here because they show how W7S detects frontend output and backend entrypoints without asking the team to split the app into separate platforms.

Custom domains are another practical difference. GitHub documents custom domain configuration for Pages, and W7S uses a similar repository-visible idea with CNAME plus DNS authorization in its custom domains docs. The W7S advantage is not merely owning a hostname; it is keeping that hostname attached to an app that can also have backend routes and bindings.

Once a site needs forms, search, uploads, status endpoints, or per-branch test data, W7S provides the next layer directly. URLs and routing describe the owner/repository URL model, while storage bindings explain how databases, key-value stores, and file buckets can be declared by the app. That gives a growing Pages-style site a path to become a small application without creating a separate backend product.

The right conclusion is measured. Stay on GitHub Pages when static publishing is the whole requirement. Move to W7S when the repository should keep its GitHub-native release flow but also needs API routes, persistent state, queues, schedules, workflows, or branch-isolated runtime resources.

This does not make GitHub Pages obsolete. It keeps Pages in its lane and gives growing projects a next step without leaving GitHub as the release surface.

Static Deploys Stay Simple​

A W7S static deploy can still be boring:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v6
        with:
          node-version: 22
      - run: npm ci
      - run: npm run build
      - uses: w7s-io/w7s-cloud@v1
        with:
          token: ${{ github.token }}

If the build output is dist/, build/, or another supported output directory, W7S publishes the static assets.

The difference is what the repository can add later without changing platform class.

Add a Backend Without Moving the Site​

With GitHub Pages, dynamic behavior usually means calling an external API. That can be fine, but the project now has two deployment surfaces: the static site and the backend.

W7S can deploy both from the same repository:

frontend/
  package.json
  dist/
backend/
  index.ts
w7s.json

The backend is a normal request handler:

export default {
  async fetch(request: Request, env: Env) {
    const url = new URL(request.url);

    if (url.pathname === "/api/status") {
      return Response.json({
        ok: true,
        repository: env.W7S_REPOSITORY,
        environment: env.W7S_ENVIRONMENT
      });
    }

    return new Response("Not found", {status: 404});
  }
};

Now the same app can serve static pages and backend routes.

Add Storage When Static State Is Not Enough​

Static sites often begin with JSON files committed to the repo. That works until the data becomes user-created, generated, private, or large.

W7S lets the app declare managed storage:

{
  "bindings": {
    "db": [
      {
        "binding": "DB",
        "migrations": "migrations"
      }
    ],
    "kv": ["CACHE"],
    "fs": ["FILES"]
  }
}

Use:

• Serverless DB for notes, forms, metadata, and app-local relational data;
• KV for small cached values and latest state;
• FS for uploaded files or generated artifacts.

The repo explains its runtime needs. The site does not have to bolt on a separate backend platform just to store a row.

Add Background Work Without a Worker Server​

Once a static site has backend routes, it often needs background behavior:

• send an email after form submission;
• regenerate a search index;
• refresh data from an external API;
• process an uploaded file;
• run a daily cleanup.

W7S covers those cases with queues and schedules:

{
  "queues": ["jobs"],
  "schedules": [
    {
      "cron": "0 0 * * *",
      "path": "/_w7s/schedules/daily"
    }
  ]
}

The backend receives queue and schedule deliveries at declared paths. There is no separate worker service to run beside the static site.

Custom Domains Stay Reviewable​

GitHub Pages supports custom domains. W7S keeps the same repository-friendly idea with a CNAME file:

docs.example.com

W7S also supports DNS authorization records that allow a domain owner to control which GitHub owner or repository may claim names under a zone.

The repository requests the hostname. DNS authorizes it. The platform maps it.

Branches Can Preview Runtime Changes​

GitHub Pages is excellent at publishing one static output. W7S branch environments are more useful when a branch changes runtime behavior:

• new backend route;
• new database migration;
• new queue;
• new schedule;
• changed environment variable list;
• changed custom domain declaration.

Non-production branches get branch-derived environments and URLs. Managed resources can be scoped by repository and environment, making previews more honest than a static artifact alone.

When GitHub Pages Still Fits Better​

Keep GitHub Pages when the site is:

• purely static;
• documentation, project pages, or a personal site;
• intentionally free of backend routes and storage;
• already using a Pages-specific workflow that is good enough;
• better served by GitHub's built-in Pages settings.

There is no reason to add an app platform when static hosting is the whole need.

Recommendation​

Start with GitHub Pages when the project is just a static site.

Move to W7S when the repository starts needing app behavior:

• backend routes;
• storage bindings;
• queues or schedules;
• branch-isolated previews;
• internal service calls;
• a runtime contract in w7s.json.

The migration path is natural because both models start from GitHub. W7S keeps that source of truth and adds the app runtime GitHub Pages deliberately does not try to be.

Many small apps do not need that much runtime. They need a frontend, a few backend routes, a database, a cache, file storage, maybe a background job, maybe a schedule, and a clean deploy path from GitHub.

For that shape, W7S can replace a process platform with a repository-native app platform.

If the app can be a request handler plus managed bindings, do not start by operating services.

The Short Mapping​

Source-Backed Comparison Points​

The platforms in this comparison are strong because they run process-oriented applications well. Heroku documents dynos and Procfile process types; Render documents web services and background workers; Railway documents projects, services, environments, and deployments in its platform docs; and Fly.io exposes low-level control through Fly Machines. Those are useful models when the app needs a real process, container, machine, or worker lifecycle.

W7S competes in a narrower and more specific lane. If the app is static assets plus a JavaScript or TypeScript backend handler, project layouts and deploys from GitHub can replace the service-definition step. The repository builds in CI, W7S receives the archive, and the runtime dispatches HTTP requests without the team choosing a process size, start command, port, machine count, or idle service behavior.

Background work is where the distinction becomes operationally important. Process platforms commonly model async work as another long-running worker process. W7S models the common small-app version as backend queues, backend schedules, and backend workflows. That removes a class of service management when the work can be delivered to a route or coordinated as a durable platform workflow.

Storage follows the same pattern. Instead of treating a database, cache, and file bucket as separate add-ons or external services for every app, W7S lets the repository declare resources with storage bindings and serverless database. For small products, that is often the difference between shipping an app and operating a set of support services around the app.

The honest boundary is containers. If a project needs arbitrary processes, custom images, private networking details, long-lived daemons, or VM-level controls, Heroku, Render, Railway, or Fly.io may remain the better fit. If the process is mostly incidental and the app naturally fits request handlers, static assets, managed bindings, queues, schedules, and workflows, W7S is a real replacement with less operational surface.

This is not a claim that W7S replaces containers. It replaces a common subset of process-platform usage where the process was mostly a packaging detail.

Processes Become Request Handlers​

On process platforms, the application usually runs a web command:

web: npm start
worker: npm run worker

or a service definition that eventually starts a long-running server.

In W7S, a native backend exports a request handler:

export default {
  async fetch(request: Request, env: Env) {
    const url = new URL(request.url);

    if (url.pathname === "/api/health") {
      return Response.json({ok: true});
    }

    if (url.pathname === "/api/orders") {
      return handleOrders(request, env);
    }

    return new Response("Not found", {status: 404});
  }
};

There is no port to bind, process size to choose, idle machine to keep warm, or web dyno count to scale. W7S owns the runtime and dispatches requests to the backend.

That is a better fit for apps whose backend work is naturally request/response.

Workers Become Queues​

Process platforms often push background work into a worker process. That worker then needs a queue, credentials, scaling rules, logs, retry behavior, and deployment coordination.

W7S makes the queue part of the app contract:

{
  "queues": [
    {
      "name": "jobs",
      "consumer": "/_w7s/queues/jobs"
    }
  ]
}

Producers enqueue through W7S_QUEUE:

export async function enqueueEmail(env: Env, payload: unknown) {
  return env.W7S_QUEUE.fetch(
    "https://w7s.internal/api/v1/queues/acme/app/jobs",
    {
      method: "POST",
      headers: {
        authorization: `Bearer ${env.W7S_QUEUE_TOKEN}`,
        "content-type": "application/json"
      },
      body: JSON.stringify(payload)
    }
  );
}

The backend consumes batches through a normal route:

if (url.pathname === "/_w7s/queues/jobs" && request.method === "POST") {
  const batch = await request.json();
  for (const message of batch.messages) {
    await sendEmail(message.body);
  }
  return Response.json({ok: true, processed: batch.messages.length});
}

The app owns the code. W7S owns the delivery mechanism.

Scheduled Jobs Become Schedules​

A process platform may use a cron add-on, scheduled job service, or always-on worker loop.

W7S schedules are declared next to the backend:

{
  "schedules": [
    {
      "cron": "0 * * * *",
      "path": "/_w7s/schedules/hourly"
    }
  ]
}

The schedule invokes the backend route:

if (url.pathname === "/_w7s/schedules/hourly") {
  await refreshReports(env);
  return Response.json({ok: true});
}

That removes a separate scheduler service for jobs that already belong to the app.

Add-Ons Become Bindings​

Heroku-style platforms popularized the add-on model. That works well, but it can scatter the runtime contract across a dashboard, environment variables, provider credentials, and app code.

W7S uses w7s.json:

{
  "bindings": {
    "db": [
      {
        "binding": "DB",
        "migrations": "migrations"
      }
    ],
    "kv": ["CACHE"],
    "fs": ["FILES"]
  },
  "vars": ["PUBLIC_API_ORIGIN"],
  "secrets": ["STRIPE_SECRET_KEY"]
}

The app receives the declared resources through env. Storage is scoped by repository and environment, so a feature branch does not need to share production resource names.

Use the right primitive:

Deployment Becomes a GitHub Workflow​

Process platforms often expose multiple deploy paths: Git push, dashboard deploy, CLI deploy, container deploy, or GitHub integration.

W7S keeps one boring default:

- uses: actions/checkout@v5
- uses: actions/setup-node@v6
  with:
    node-version: 22
- run: npm ci
- run: npm run build
- uses: w7s-io/w7s-cloud@v1
  with:
    token: ${{ github.token }}

If the app needs tests, migrations, type checks, generated files, or a custom build directory, put those steps in the workflow. The release behavior is code-reviewed with the app.

What You Give Up​

W7S is not a process platform. Do not replace Heroku, Render, Railway, or Fly.io with W7S if the app needs:

• arbitrary containers;
• long-running daemons;
• custom TCP listeners;
• WebSocket-heavy always-on services that need process-level control;
• language runtimes outside the W7S native backend model;
• private networks with process services;
• manual machine sizing and placement;
• shell access into a running container;
• process supervisors or multi-process containers.

Those are real platform needs. Use a process platform when the process is the product.

Recommendation​

Use W7S when the app can be reduced to:

• static assets;
• JavaScript/TypeScript request handlers;
• managed DB, KV, FS, queues, schedules, and workflows;
• GitHub Actions as the release boundary;
• branch environments instead of long-lived staging services.

Keep a process platform when the app genuinely needs a process.

The important distinction is not "simple versus serious." It is runtime shape. A serious app can be static assets plus request handlers and managed bindings. For that shape, W7S removes service management that was never central to the product.

That flexibility is also why Kubernetes is often too much for small apps.

Many apps do not need a cluster. They need:

• a frontend;
• a few backend routes;
• a database;
• file storage;
• a background queue;
• a schedule;
• a durable workflow;
• a deploy path from GitHub;
• logs and usage feedback.

W7S is designed for that smaller shape.

The Short Mapping​

Source-Backed Comparison Points​

Kubernetes is broad infrastructure, not a small-app deployment product. Its official docs cover Deployments, Services, Ingress, Jobs, and CronJobs as separate concepts. That separation is powerful for platform teams, but it is a lot of surface area for a small app that only needs a frontend, a few routes, and some managed state.

W7S replaces that cluster vocabulary with a repository vocabulary. Deploying from GitHub defines the release mechanism, project layouts define what the archive can contain, and URLs and routing define how owner/repo identity becomes a public app URL. The result is less flexible than Kubernetes, but much easier to standardize for apps that fit the model.

For background work, Kubernetes has Jobs and CronJobs. W7S maps the small-app cases to backend queues, backend schedules, and backend workflows. That means the team can express async work as app behavior instead of maintaining queue workers, job manifests, schedule objects, service accounts, and cluster-level operational policy for every small service.

State also moves from infrastructure objects to app bindings. Kubernetes can support persistent volumes, operators, and external managed databases, but that usually creates more platform decisions. W7S storage bindings and serverless database give a smaller default: declare the app resource, let the platform provision it per repository and environment, and keep the runtime access path in code.

The replacement claim should stay precise. W7S is not trying to run arbitrary containers, service meshes, custom controllers, or cluster-native workloads. It is a replacement for the recurring case where Kubernetes is being used as a deploy substrate for an app that could be static assets, request handlers, managed bindings, queues, schedules, and workflows.

This is not "Kubernetes is bad." It is "do not turn every small app into a cluster-management problem."

Containers Become Native Backends​

Kubernetes runs containers. That is the right abstraction when the application needs arbitrary runtimes, process managers, system packages, sidecars, or long-running daemons.

W7S native backends use a narrower contract:

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const url = new URL(request.url);

    if (url.pathname === "/api/health") {
      return Response.json({ok: true});
    }

    return new Response("Not found", {status: 404});
  }
};

The benefit is that the app no longer owns:

• container images;
• pod specs;
• service selectors;
• ingress resources;
• health probes;
• horizontal autoscaling config;
• node scheduling concerns.

If the app fits the backend handler model, that missing surface is a feature.

Services Become Repository Routes​

Kubernetes separates pods from Services and exposes traffic through Service and Ingress resources.

W7S uses repository identity:

https://acme.w7s.cloud/checkout/
https://feature-payments--acme.w7s.cloud/checkout/

Internal service calls use Backend RPC:

const response = await env.W7S_RPC.fetch(
  "https://w7s.internal/api/v1/rpc/acme/auth/session",
  {
    headers: {
      authorization: `Bearer ${env.W7S_RPC_TOKEN}`
    }
  }
);

That is not as general as Kubernetes networking, but it is enough for many HTTP-shaped app systems. The service boundary is the repository.

ConfigMaps and Secrets Move to the Deploy Contract​

Kubernetes uses ConfigMaps and Secrets as API objects. W7S keeps common app configuration in the repository and GitHub workflow:

{
  "vars": ["PUBLIC_API_ORIGIN"],
  "secrets": ["STRIPE_SECRET_KEY"]
}

- uses: w7s-io/w7s-cloud@v1
  env:
    PUBLIC_API_ORIGIN: ${{ vars.PUBLIC_API_ORIGIN }}
    STRIPE_SECRET_KEY: ${{ secrets.STRIPE_SECRET_KEY }}
  with:
    token: ${{ github.token }}

The app reads values from env. Deploy summaries can count secrets without exposing secret values.

For dynamic product configuration, use KV or DB rather than redeploying platform config.

Persistent Volumes Become App Storage Bindings​

Kubernetes volumes are infrastructure-level storage. Many small apps need app-level storage instead:

• SQL rows;
• cache entries;
• uploaded files;
• per-entity durable state.

W7S declares those directly:

{
  "bindings": {
    "db": [
      {
        "binding": "DB",
        "migrations": "migrations"
      }
    ],
    "kv": ["CACHE"],
    "fs": ["FILES"],
    "durableObjects": [
      {
        "binding": "SESSION",
        "className": "Session"
      }
    ]
  }
}

This keeps storage at the level the application understands. A small app usually should not need to pick a storage class before it can save user settings.

Jobs and CronJobs Become Queues, Schedules, and Workflows​

Kubernetes Jobs and CronJobs are useful for containerized work. W7S maps app-level background work to platform primitives:

{
  "queues": ["jobs"],
  "schedules": [
    {
      "cron": "0 * * * *",
      "path": "/_w7s/schedules/hourly"
    }
  ],
  "workflows": ["checkout"]
}

Use:

• queues for async work that can retry;
• schedules for time-based triggers;
• workflows for durable business processes with status.

This is less general than running any container as a job, but it fits the common app cases without introducing cluster resources.

Operators Become Platform Provisioning​

Kubernetes operators are powerful because they encode domain-specific operations into the cluster.

For small apps, many operator-like needs are common enough that W7S can own them:

• create a DB binding;
• apply SQL migrations;
• create a KV namespace;
• create a file bucket;
• wire a queue to a backend route;
• wire a schedule to a backend route;
• wire a workflow to a backend route;
• inject runtime bindings;
• account for usage by repository and environment.

The app declares intent in w7s.json; W7S handles the provisioning path.

That is not a replacement for custom operators. It is a replacement for needing operators before the app has operator-scale needs.

GitHub Actions Replaces the Release Pipeline Layer​

Kubernetes deploys often grow a release stack:

• image build;
• registry push;
• manifest render;
• Helm or Kustomize;
• kubectl apply;
• rollout status;
• environment promotion;
• secret management.

W7S keeps the default smaller:

- uses: actions/checkout@v5
- uses: actions/setup-node@v6
  with:
    node-version: 22
- run: npm ci
- run: npm run build
- uses: w7s-io/w7s-cloud@v1
  with:
    token: ${{ github.token }}

For apps that fit the W7S runtime, this removes entire categories of release machinery.

What Kubernetes Still Does Better​

Use Kubernetes when the app or organization needs:

• arbitrary containers and languages;
• long-running processes;
• private cluster networking;
• service mesh behavior;
• custom controllers and operators;
• GPU workloads;
• stateful sets and storage classes;
• TCP or non-HTTP services;
• strict multi-tenant cluster policy;
• existing platform engineering built around Kubernetes;
• workloads that must run inside a specific VPC or cloud account.

Those needs are real. W7S should not pretend to cover them.

Recommendation​

Use W7S for small apps that can be:

• static assets;
• JavaScript/TypeScript native backends;
• managed storage bindings;
• queues, schedules, and workflows;
• GitHub Actions deploys;
• branch environments.

Use Kubernetes when the workload truly needs a cluster.

The mistake is not choosing Kubernetes. The mistake is choosing Kubernetes before the application has Kubernetes-shaped problems.

W7S does not need to copy that model to support the same application patterns. In many W7S apps, adding NATS would introduce another control plane, another credential model, another operational surface, and another local development story. The better default is to ask a narrower question:

Can the same product behavior be built from W7S components we already have?

For many cases, the answer is yes.

The Short Mapping​

Source-Backed Comparison Points​

NATS is a messaging system with a clear and useful model. Its docs cover publish-subscribe, request-reply, queue groups, and JetStream for persistence and streaming. That is exactly the right tool when the application needs broker semantics across many services, languages, or hosts.

The W7S replacement is intentionally narrower. Synchronous service-to-service calls map to Backend RPC, where the caller and target are repository-scoped W7S apps. Async work maps to backend queues, where a known consumer handles delivered jobs. Time-based production of work maps to backend schedules, and longer business processes map to backend workflows.

Durability needs a more careful answer than "use queues." If the app needs replayable event history, audit trails, or large payload storage, W7S should pair queue dispatch with serverless database records or storage bindings for object/file payloads. That is not the same as JetStream, but it does cover many product-level event flows where the event log is part of the application's own data model.

Local testing is also different. NATS gives developers a local broker. W7S gives developers w7s-local and HTTP-shaped service boundaries, which are documented in the W7S local examples and work well when the goal is to test RPC and route behavior between repos. That keeps development close to the deployed W7S shape instead of introducing a second messaging topology just for tests.

The honest recommendation is to avoid adding NATS until the app truly needs broker semantics. If the product needs subjects, wildcard subscriptions, queue groups, and streaming as core architecture, use NATS. If it needs W7S apps to call each other, queue jobs, fan out known events, schedule work, and persist product state, W7S components can replace the broker with less platform surface.

This is not a claim that W7S is a drop-in NATS server. It is a design choice: use W7S-native components for app-level messaging, and reserve NATS for projects that truly need broker semantics.

Request/Reply Becomes Backend RPC​

NATS request/reply is often used when one service needs an answer from another service right now:

• auth service returns a session;
• billing service returns entitlement state;
• inventory service returns availability;
• internal API returns a computed result.

That maps cleanly to W7S Backend RPC.

type Env = {
  W7S_RPC: Fetcher;
  W7S_RPC_TOKEN: string;
};

export default {
  async fetch(request: Request, env: Env) {
    const response = await env.W7S_RPC.fetch(
      "https://w7s.internal/api/v1/rpc/acme/auth/session",
      {
        headers: {
          authorization: `Bearer ${env.W7S_RPC_TOKEN}`,
          cookie: request.headers.get("cookie") ?? ""
        }
      }
    );

    if (!response.ok) {
      return new Response("Auth service unavailable", {status: 502});
    }

    const session = await response.json();
    return Response.json({session});
  }
};

The target backend receives a normal HTTP request at the target path. W7S resolves the caller from the deployment token, loads the target deployment in the same environment, checks cross-owner authorization when needed, and injects caller identity headers into the target request.

This has a few advantages over introducing a broker for request/reply:

• the call path is HTTP-shaped and easy to debug;
• same-owner apps can call each other without extra manifest work;
• cross-owner calls stay target-controlled through rpc.allow;
• usage accounting can attribute the dispatch to the caller app;
• branch environments naturally call the matching target environment.

Use RPC when the caller needs the response before it can finish its own response.

Work Queues Become W7S Queues​

NATS queue groups are useful when work should be processed asynchronously by one of several workers. In W7S, the queue is owned by a target repository, and producers send JSON messages through the W7S queue binding.

{
  "queues": [
    {
      "name": "jobs",
      "consumer": "/_w7s/queues/jobs"
    }
  ]
}