Our verdict
-
Choose for workflow
Consider Netlify when previews and configuration are the reason to switch.
Local static serving, redirects and GET/POST Functions passed. Hosted behavior remains untested.
-
Budget publishing
300 credits are shared across deploys and traffic.
At the documented 15 credits per production deploy, 20 publications alone consume the allowance. That is arithmetic, not an observed bill.
At a glance: good local tooling, a shared hosting budget
Netlify is worth considering when preview deployments, redirect rules and small serverless endpoints are part of your release process. Its new-account Free plan is a bounded experiment: the same 300 monthly credits cover publishing, traffic and compute. A quiet site can spend that allowance just by being published repeatedly. The current pricing page and credit documentation matter more than old articles describing separate build-minute and bandwidth allowances.
Our hands-on scope is local. Netlify signup returned a security-check error. We did not complete a hosted deployment, observe a credit balance, measure the CDN or test production Functions. We did run Netlify CLI 27.10.2 offline on Node 22.23.3, serve a static page, invoke a Function, and verify routing and headers. The local Function returned 200 in all 50 measured GETs: median 161.313 ms, p95 225.998 ms. These are development-server timings, not a promise about hosting speed.
What we tested and how to reproduce it
The fixture contains one HTML file, one JavaScript Function and a netlify.toml. The Function uses the Web Request/Response interface: GET returns a small JSON object, while POST echoes a JSON body. The browser screenshot comes from the real running fixture. No vendor account, payment method or hosted site was needed for these local checks. Netlify documents this local workflow in its CLI guide and the runtime interface in its Functions documentation.
netlify dev --offline --no-open --skip-gitignore --dir /absolute/path/to/fixture/public --functions /absolute/path/to/fixture/functions --port 5683 We used explicit absolute paths because this fixture lived inside the sudoai.net repository. Our first run loaded the parent repository’s go Function instead of the fixture’s echo Function. Its rewritten endpoint returned 404. Supplying both paths loaded echo and fixed the problem. This is a monorepo/configuration discovery observation in our run; we did not establish a general CLI defect.

| Check | Observed result | What it establishes |
|---|---|---|
| GET / | 200 | Static HTML served |
| GET /api/echo | 200, JSON | 200 rewrite reaches the Function |
| POST /api/echo | 200, echoed message and sequence | JSON request body survives routing |
| GET /.netlify/functions/echo | 200 | Direct Function route works |
| GET /missing | 404 | Unknown path does not silently become a success |
| X-SudoAI-Test response header | local-fixture | Configured static header was applied |
The measurement: 50 requests through Netlify Dev
We made one unreported warmup GET, then 50 sequential GETs to /api/echo using Python Requests. Each sample includes local HTTP transport and the development proxy/function process. There was no load generator, intentional parallelism or internet hop. Tests ran on this Linux box; its physical location and provider capacity were not independently verified. An Asia/Singapore timezone does not prove Singapore network egress.
| Metric | Measured value |
|---|---|
| Samples / status | 50 / all HTTP 200 |
| Median | 161.313 ms |
| p95 (nearest-rank sample 48/50) | 225.998 ms |
| Range | 147.093–235.456 ms |
| Warmup | 161.252 ms; excluded |
| Hosted deploy / cold start / credit consumption | Not tested |
The relatively large local latency is a reason to measure the deployed route before deciding, not evidence that Netlify’s CDN is slow. Development emulation and production execution have different processes and scheduling. We retained both the initial failed routing run in logs and the successful functional checks; the table reports only the final corrected 200-response sample.
Free-plan limits that affect an indie release schedule
These values are documented, not limits we reached. Prices and limits were checked Oct 1, 2026. New accounts have used credit-based plans since September 4, 2025; eligible older accounts can retain legacy plans. Switching to credits is irreversible according to the plan documentation. Read your own dashboard before applying this table to an existing account.
| Meter / feature | Current documented Free behavior | Practical consequence |
|---|---|---|
| Monthly allowance | 300 credits, hard limit | No Free auto-recharge; unused monthly credits do not roll over |
| Successful production publication | 15 credits per deploy | 20 publications exhaust 300 credits before traffic or compute |
| Preview / branch publication | 0 deploy credits | Their traffic still consumes bandwidth and request credits |
| Bandwidth | 20 credits / GB | Assets and Function responses share the budget |
| Web requests | 2 credits / 10,000 requests | Asset requests and redirects count, not just HTML page views |
| Compute | 10 credits / GB-hour | Memory allocation × execution duration matters |
| Forms submissions | Free on credit plans | Do not reuse outdated per-form credit arithmetic |
| Concurrent builds | 1 | Separate preview branches can still queue |
| Team member | 1 free member | Unlimited reviewers are not unlimited developers |
All meter rates above come from how credits work; concurrency and members come from the plan comparison. When the credit balance is exhausted, the documentation says all web projects on that balance pause. We did not deliberately exhaust credits and cannot show the pause page from our own account.
Three budget examples, calculated rather than measured
| Assumptions | Calculated credits | Reading |
|---|---|---|
| 10 production deploys, no other usage | 10 × 15 = 150 | Half the allowance is spent publishing |
| 4 production deploys + 5 GB + 100,000 requests | 60 + 100 + 20 = 180 | 120 credits remain before compute or AI |
| Daily production deploy for a 30-day month | 30 × 15 = 450 | Exceeds Free before anyone visits |
These scenarios are arithmetic using the published rates, not invoices or observed quotas. Actual metering granularity and the dashboard’s rounding were not tested. AI inference is another shared-budget expense; this review did not invoke models, Agent Runners, a database or any paid add-on. Keeping an unused AI feature out of a hosting estimate is sensible, but enabling it later requires a fresh budget.
What user reports add—and what they do not prove
A saved Hacker News search includes a developer reporting that frequent scheduled rebuilds burned their credit allocation and that they moved the build schedule to GitHub Actions (original comment). Another commenter describes adding credits after HN traffic increased demand (original comment). These are individual reports, not our reproduction. The actionable point agrees with the official shared-budget model: publishing cadence and traffic compete for the same allowance.
GitHub issue #8423 reports Functions failing when netlify dev --cwd is invoked outside a project. We did not reproduce that specific error; our problem was resolving the Function folder. The distinction matters when troubleshooting. A Reddit credit-pause discussion was found, but direct retrieval returned 403, so it is not used as factual evidence here.
Netlify or Cloudflare for this workflow?
If your app mainly serves static files and makes a few API requests, read our Cloudflare Pages hands-on review beside this one. That article includes an actual hosted deploy; this article cannot offer an equivalent Netlify hosting benchmark. Our site runs on Cloudflare Pages, so migrating merely to repeat static hosting would need a concrete preview, integration or operational benefit.
Netlify’s named deployment contexts and Function routing are useful when an existing team workflow is already built around its configuration. For a new small site, first estimate publications, transfer and request volume. Using an external build runner does not by itself remove Netlify’s production-publication charge. Fewer builds, fewer production publishes and smaller assets address different meters.
Do not confuse ordinary Functions with Edge Functions. They have different execution environments; code and dependency compatibility should be tested in the environment you will actually deploy. Our fixture is a regular Function. We did not validate Edge Functions, provider regions, function timeouts, production concurrency or cold starts.
The paid step and migration checks
The current public plans list Personal at $9/month with 1,000 credits and Pro starting at $20/month with 3,000 credits and unlimited members. Pro has additional credit tiers. Those are subscription prices, not all-in quotes: optional recharge and add-ons can add cost. Every paid tier is not tested. The April 2026 pricing announcement and changelog help explain why older articles about per-seat pricing may disagree.
Before moving production, make a preview deploy and test redirects, security headers, environment-variable contexts, asset caching and the real function URL. Test a failing Function and a rollback as well as a happy-path request. Confirm whether production becomes public only after publication in your account’s current workflow. Finally, alert on the shared credit balance and identify who can publish. None of these hosted checks was completed in this run.
What would change our verdict?
A real free account with a successful deploy, measured publication time, before/after credit screenshots and external latency would let us assess hosting rather than tooling. Until then, our verdict is limited: Netlify Dev is usable for this tiny static-plus-Function fixture after setting explicit paths; the documented credit model needs a release budget. We will not rank its production performance from localhost numbers.
Who should not use this
Avoid choosing Netlify Free for daily production publishing without estimating credit usage, or for a team that needs multiple developer seats on Free. Do not choose it on the strength of our localhost latency: hosted Free and all paid tiers are not tested.
On this page · 9 sections
- Our verdict
- At a glance: good local tooling, a shared hosting budget
- What we tested and how to reproduce it
- The measurement: 50 requests through Netlify Dev
- Free-plan limits that affect an indie release schedule
- What user reports add—and what they do not prove
- Netlify or Cloudflare for this workflow?
- The paid step and migration checks
- What would change our verdict?