Coder Legion - Recent posts tagged vercel

Vercel Was Too Expensive, So I Migrated My Next.js App to Cloudflare Workers

Thu, 15 Oct 2026 00:06:44 +0000

I recently moved production traffic for Galaxy Movies, my Next.js movie/TV discovery site, off Vercel and onto Cloudflare Workers. Nothing against Vercel. Vercel is a great platform, and the app ran happily there for a long time. But I was paying for a Pro plan for what is ultimately a side project, my DNS was already on Cloudflare, and the entire backend surface is fetch-based (Upstash REST, OpenAI, Resend, TMDB); no databases, no TCP. That's about as close to a best-case scenario for running Next.js on workers as you can get.

The site is Next.js 16 Pages Router, React 19, Chakra UI, with ISR catalog pages, a pile of API routes, four Vercel cron jobs, and dynamic OG images via next/og. Here's what the migration actually looked like, including the parts that fought back.

The adapter: @opennextjs/cloudflare
The OpenNext Cloudflare adapter takes a standard next build output and rebundles it into a worker. Setup is two files. First, open-next.config.ts. The interesting bit is the incremental cache override, which points ISR's cache at an R2 bucket:

import { defineCloudflareConfig } from '@opennextjs/cloudflare'

import r2IncrementalCache from '@opennextjs/cloudflare/overrides/incremental-cache/r2-incremental-cache'

export default defineCloudflareConfig({

  default: { experimentalBundledNextServer: true },

  incrementalCache: r2IncrementalCache

})
Then wrangler.jsonc:

{

  "main": ".open-next/entry.js",

  "name": "galaxy-movies",

  "compatibility_flags": ["nodejs_compat", "global_fetch_strictly_public"],

  "assets": { "directory": ".open-next/assets", "binding": "ASSETS" },

  "services": [{ "binding": "WORKER_SELF_REFERENCE", "service": "galaxy-movies" }],

  "r2_buckets": [

    { "binding": "NEXT_INC_CACHE_R2_BUCKET", "bucket_name": "galaxy-movies-inc-cache" }

  ],

  "triggers": { "crons": ["0 6 * * *", "30 6 * * *", "0 7 * * *", "0 16 * * 5"] },

  "find_additional_modules": true,

  "rules": [

    { "type": "Data", "globs": ["public/fonts/**", "public/backdrop_fallback.jpg"], "fallthrough": true }

  ]

}

Deploy is two commands: opennextjs-cloudflare build then wrangler deploy. Everything below is the gap between "two commands" and "actually works in production."

Gotcha 1: Next's dev-only require()s break the bundle
The adapter bundles the Next server with esbuild, and esbuild wants every require() to resolve, including dev-only code paths inside Next's own dist files (next-dev-server, setup-dev-bundler, an upgrade nudge) and an RSC-only path (react-server-dom-webpack) that a Pages Router app never executes. They're dead code in production, but dead code still has to resolve.

I fixed it with patch-package to mark them external in the adapter's bundle step, plus a postbuild script that drops tiny stub modules where the runtime resolution lands:

// scripts/opennext-postbuild.js: runs after opennextjs-cloudflare build

fs.writeFileSync('.../dev/next-dev-server.js', 'module.exports = {}\n')

fs.writeFileSync('.../router-utils/setup-dev-bundler.js', 'module.exports = {}\n')

// ...etc

The patch also adds preview-props.json to the manifest glob the adapter uses, which the Pages Router build emits, and the adapter wasn't collecting. Not elegant, but it's contained in patches/ and reapplied on every npm install by patch-package. If the upstream adapter fixes these, the patch just stops applying cleanly, and I delete it.

Gotcha 2: next/og picks the wrong runtime
This one took the longest. I generate OG images with next/og, which wraps @vercel/og. The library has two entries: a Node build that does readFileSync on a bundled font and calls WebAssembly.instantiate at runtime (both disallowed on workerd), and an edge build that doesn't.

The problem: OpenNext forces NEXT_RUNTIME="nodejs" at bundle time, so next/og always resolves the Node entry, even inside a worker. The workaround is sniffing the runtime myself and importing the edge build directly:

const { ImageResponse } = (await (globalThis.navigator?.userAgent === 'Cloudflare-Workers'

  ? import(/* webpackIgnore: true */ 'next/dist/compiled/@vercel/og/index.edge.js')

  : import('next/og'))) as { ImageResponse: typeof ImageResponseType }

Navigator.userAgent === 'Cloudflare-Workers' is genuinely how you detect workerd. The webpackIgnore comment keeps webpack from trying to bundle the path at build time, and I pin the whole @vercel/og compiled directory into the output via outputFileTracingIncludes in next.config.ts so the edge build and its resvg wasm actually ship.

Gotcha 3: fs reads land in the wrong directory
My OG route also reads custom fonts and a fallback backdrop off disk with readFile(path.join(process.cwd(), 'public', ...)). On Vercel, process.cwd() is the project root. On workerd, the vfs cwd is /bundle (the .open-next output root), so public/fonts doesn't exist where the code looks for it.

The fix is a three-part move: the postbuild script copies public/fonts and backdrop_fallback.jpg into .open-next/public/, and wrangler's find_additional_modules + the Data rules in wrangler.jsonc ship those files in the worker's virtual filesystem. Same code path; files just exist where the worker looks.

Gotcha 4: packages hiding behind the workerd export condition
Some packages, in my case @emotion/* (Chakra's styling engine) and uncrypto, publish their ESM builds behind a workerd export condition. Next's file tracer only follows the CJS variants, so the worker bundle ends up with nothing it can resolve for those imports.

The fix is listing them in serverExternalPackages in next.config.ts, which tells the adapter to copy the packages whole instead of relying on tracing:

serverExternalPackages: [

  '@emotion/react', '@emotion/cache', '@emotion/serialize',

  '@emotion/sheet', '@emotion/weak-memoize', '@emotion/hash',

  '@emotion/memoize', '@emotion/unitless', '@emotion/utils',

  '@emotion/use-insertion-effect-with-fallbacks',

  'hoist-non-react-statics', 'uncrypto'

]

If you hit "cannot resolve module" errors on workerd that don't reproduce locally, this is the first thing to check.

Gotcha 5: Vercel crons don't exist on Workers
vercel.json crons are a Vercel platform feature; nothing in a Next.js build output describes them. On Workers, the equivalent is triggers.crons + a scheduled() handler. But the adapter generates worker.js, so I wrap it in a custom entry that adds the handler and maps each cron expression back to the same endpoint Vercel used to hit:

// .open-next/entry.js, written by the postbuild script

import worker from './worker.js'

const CRON_ROUTES = {

  '0 6 * * *': '/api/cron/generate-content',

  '30 6 * * *': '/api/cron/streaming-changes',

  '0 7 * * *': '/api/cron/watchlist-alerts',

  '0 16 * * 5': '/api/cron/weekly-digest'

}

export default {

  ...worker,

  async scheduled(event, env, ctx) {

    const route = CRON_ROUTES[event.cron]

    if (!route) return

    ctx.waitUntil(

      env.WORKER_SELF_REFERENCE.fetch(

        new Request('https://worker.internal' + route, {

          headers: { authorization: 'Bearer ' + env.CRON_SECRET }

        })

      )

    )

  }

}

Two things make this nice. The WORKER_SELF_REFERENCE service binding lets the worker call itself as an internal fetch, no public round trip. And the endpoints needed zero changes: they already checked Authorization: Bearer $CRON_SECRET because that's how Vercel's cron caller authenticates too. Testing is wrangler dev --test-scheduled, then hit /__scheduled?cron=0 6 *.

Secrets
wrangler secret bulk takes a JSON file, so a 20-line script converts .env.local into .secrets.json, skipping NEXTPUBLIC* vars (those get inlined at build time anyway) and my local Cloudflare API token. npm run cf:secrets and done: no dashboard clicking through a dozen vars.

Cutover and rollback
The safest part of the whole migration was the cutover itself, because I deliberately ran both platforms in parallel:

npm run cf:deploy, then verify everything on the *.workers.dev URL (all routes, OG images, cron triggers registered).
Attach the galaxymovies.app + www custom domains to the worker. Since DNS was already on Cloudflare, this was instant, no propagation wait.
Keep Vercel as cold standby: git.deploymentEnabled.main: false in vercel.json stops main pushes from auto-deploying, and I disabled the Vercel crons in the dashboard so the two platforms don't double-fire jobs.

Rollback is re-adding two DNS records (A to Vercel's anycast IP, CNAME www to the Vercel DNS name). Traffic flips back immediately because the worker custom domains only take precedence while they're the only records on those names. That escape hatch made the whole thing low-stress: worst case is a DNS edit, not a redeploy.

What's actually running
Same codebase, same next build, no platform fork in the source. SSR, ISR (backed by R2), all API routes, the OG image route, and all four crons work identically to how they did on Vercel. The only code that knows which platform it's on is that one navigator.userAgent check in the OG route.

The honest summary: the adapter gets you ~80% there out of the box, and the remaining 20% is the kind of platform-shim work above. It's tractable, but expect an afternoon of debugging, not a lunch break. If your app leans on Node APIs that aren't fetch-shaped, the logic is different. But if you're already edge-friendly and your DNS is on Cloudflare anyway, the economics are hard to argue with, and Vercel sitting dormant as a free rollback target is a pretty nice safety net.

Repo notes worth taking if you're doing this: patch-package for the adapter externals, a postbuild script for stubs + vfs assets + the cron entry, serverExternalPackages for workerd-conditioned packages, and wrangler dev --test-scheduled for cron testing.

Happy to answer questions in the comments!

Is Vercel Speed Insights enough for Core Web Vitals monitoring?

Sun, 04 Oct 2026 06:55:01 +0000

Strong first-party RUM on Vercel projects. Not a multi-client PageSpeed portfolio. Here is when it is enough, and when it is not.

Agencies often turn on Vercel Speed Insights for a Next.js client, see route-level Core Web Vitals, and assume monitoring is “done.” For that Vercel project, the product is genuinely useful. For a book of WordPress, Shopify, Magento, and mixed hosts, it is not enough. Core Web Vitals monitoring means knowing when Largest Contentful Paint, Interaction to Next Paint, or Cumulative Layout Shift moves on the URLs you promised to watch. Host RUM answers that for instrumented Vercel deployments. It does not schedule lab checks across thirty other origins or give you one organisation view for account leads.

What follows draws a clean line: when Speed Insights is enough, when you still need PageSpeed Insights field (Chrome UX Report) and scheduled lab coverage, and how agencies usually split the stack. For the synthetic-versus-field vocabulary, see When to Use Synthetic vs Real User Monitoring. For how agencies assemble DIY, portfolio, and RUM-plus-monitor recipes, see 3 Agency PageSpeed Stacks for 2026.

What Vercel Speed Insights actually measures

Vercel’s Speed Insights is first-party real-user monitoring for projects on Vercel. It collects Core Web Vitals and related timings from visitors on your deployed previews and production. The dashboard supports filters by route, device, time range, and (on paid Speed Insights tiers) richer breakdowns such as element-level views and geography. Vercel also stresses shorter windows than Google’s typical 28-day Chrome UX Report aggregation, which helps engineering see the effect of a deploy sooner.

That is RUM scoped to the Vercel runtime and their collector. It is not Lighthouse. It is not a cold lab load from Google’s PageSpeed Insights workers. It is not a multi-tenant agency console for sites that never deploy to Vercel.

Free and Plus packaging change how much detail you see (Vercel documents Real Experience Score on every plan, with fuller Core Web Vitals breakdowns on Plus). Pricing and feature gates move; treat the docs as source of truth for what your client’s plan includes.

Where Speed Insights beats PageSpeed Insights for engineering

PageSpeed Insights field data is Chrome UX Report: Chrome users, eligibility thresholds, origin or URL when sample size allows, rolling roughly 28-day window. That dataset matters for SEO conversations because it aligns with what Google publishes for page experience. It is a poor day-to-day triage tool when you need “which route broke after yesterday’s merge?”

Speed Insights wins for Vercel engineering when you need:

Route-level RUM on your own traffic, including browsers CrUX undersamples.
Faster iteration windows after a deploy or branch, instead of waiting on a long CrUX lag.
Attribution that names routes (and, on higher tiers, elements) instead of a single origin badge.

Vercel’s own Core Web Vitals guides make the same split: use CrUX / PageSpeed Insights field for the SEO-facing view; use Speed Insights (or another RUM path) for engineering triage on the Vercel app. Treat those as complementary field sources, not substitutes.

Where it is not enough for agency portfolios

Agencies fail when they generalise from one Vercel client to the whole book.

Hosts that are not on Vercel. Most retained sites still run on WordPress hosts, Shopify, Magento, static elsewhere, or custom VPS stacks. Speed Insights does not cover those origins. You still need scheduled lab tests (PageSpeed Insights API / Lighthouse-class runs), CrUX where published, and a place to store history per client organisation.

No shared multi-tenant workflow. Account leads need one login, roles, budgets, alerts, and client-ready reports across many domains. A Vercel project dashboard per deployment is the wrong primitive for that job.

Lab diagnosis still matters. RUM tells you users felt a regression. Lab (and PageSpeed Insights opportunities) still help engineers reproduce LCP and CLS causes on a cold load. Speed Insights does not replace that diagnostic loop.

CrUX remains the SEO reference. When a sponsor asks “what does Google show?”, answer with Search Console or PageSpeed Insights field / CrUX, not only your first-party RUM chart. The two can disagree (browser mix, window length, URL versus origin). Label both.

Enough when: the engagement is one Vercel-hosted product, engineering owns the Vercel dashboard, and you only promise route-level RUM plus occasional CrUX checks for SEO.

Not enough when: you sell portfolio monitoring across many client hosts, need discovery and schedules without a snippet on every domain, or need white-label reporting for non-Vercel properties.

A practical stack split

Job	Prefer
Route RUM on a Vercel Next.js app	Vercel Speed Insights (or equivalent first-party RUM)
SEO-facing field categories	CrUX via Search Console / PageSpeed Insights field
Cold-load lab + opportunity text	PageSpeed Insights lab or scheduled PSI-style monitoring
Many client sites, one org, budgets/alerts	Multi-tenant portfolio monitor (see the agency stack recipes linked above)

A common agency pattern: keep Speed Insights on the Vercel flagship; put scheduled lab-plus-CrUX monitoring on the rest of the portfolio; use CrUX as the shared SEO language in retainer packs. That matches the “RUM + monitor” stack idea without pretending one product covers every host.

Do not disable Speed Insights to “avoid duplicate tools.” Duplicate tools are fine when they answer different questions. Duplicate unlabelled numbers in a client PDF are not.

FAQ

Does Speed Insights replace PageSpeed Insights?

No. Use Speed Insights for Vercel RUM triage. Use PageSpeed Insights (or Search Console) when you need CrUX-aligned field categories and lab diagnostics on a public URL.

Can I rely on Speed Insights alone for SEO?

Risky. Google’s published field story is CrUX. First-party RUM helps you ship fixes faster; it is not the same dataset Search Console shows.

What if only one of twenty clients is on Vercel?

Instrument that one with Speed Insights. Monitor the other nineteen with a host-agnostic schedule. Do not wait for every client to migrate to Vercel before you watch regressions.

Is free Speed Insights “enough”?

Enough for a basic Real Experience Score on a Vercel project may be. Enough for element-level and geographic triage depends on the paid tier your client enables. Check Vercel’s current plan matrix before you promise those views in a retainer.

What to do next

List every production origin on the retainer. Mark which ones deploy on Vercel. Turn on Speed Insights (and the right paid tier) only where the runtime supports it. For every other origin, pick a scheduled lab-plus-CrUX path and write budgets in the same units you already use in client reviews. Put both field sources in the pack with labels: “Vercel RUM (this app)” versus “CrUX / PageSpeed Insights field (SEO window).”

If you are choosing the portfolio half of the stack, start from the three recipes in 3 Agency PageSpeed Stacks for 2026 and the lab-versus-RUM framing in When to Use Synthetic vs Real User Monitoring.

References

Speed Insights Overview (Vercel docs)
How to improve Core Web Vitals (Vercel)
How Core Web Vitals affect SEO (Vercel)
3 Agency PageSpeed Stacks for 2026 (Apogee Watcher)
When to Use Synthetic vs Real User Monitoring for Performance (Apogee Watcher)

Originally published on Hashnode.

From Static Page to Evidence-Aware Knowledge Explorer: What We Implemented in MyZubster

Wed, 23 Sep 2026 05:23:18 +0000

From Static Page to Evidence-Aware Knowledge Explorer: What We Implemented in MyZubster

MyZubster Knowledge Explorer started as a static page listing domains and canonical records.

The content was useful, but the interaction model was too flat: domains, records, evidence states and details all competed for attention in one page.

We rebuilt the explorer as a lightweight, evidence-aware static interface and deployed it to Vercel.

Live page:

https://myzubster-knowledge-myzubster.vercel.app/knowledge.html

The implementation

The deployment remains intentionally simple:

public/
└── knowledge.html

No framework runtime. No additional backend. No database migration.

The page contains:

responsive CSS;
a client-side record registry;
dynamic domain navigation;
full-text search;
evidence-state filtering;
selectable record cards;
an inline detail panel.

The record model is minimal:

{
  id: "MZ-001",
  title: "Knowledge Layer — canonical record protocol",
  domain: "MyZubster",
  state: "PROTOCOL",
  description: "Defines the Knowledge Explorer as a catalogue of traceable records..."
}

This is enough to make records searchable, classifiable and inspectable without pretending that the UI is already a full verification system.

Evidence states are part of the data model

The key decision was to make evidence classification explicit:

PERSONAL_PRACTICE
OBSERVATION
EXTERNAL_SOURCE
PROTOCOL

These are not visual tags only.

They communicate what a record is:

a first-hand practice;
a documented observation;
an identifiable external source;
or a proposed protocol.

A record can be useful without being verified guidance.

That distinction is essential when the catalogue includes technical workflows, community practices, circular-economy proposals and health-adjacent product knowledge.

Filtering records

The page combines domain selection, evidence state and text search in one filtering function:

const list = records.filter((record) =>
  (active === "All" || record.domain === active) &&
  (!state || record.state === state) &&
  `${record.id} ${record.title} ${record.domain} ${record.description}`
    .toLowerCase()
    .includes(query)
);

This keeps the first version dependency-free and deterministic.

For a small catalogue, a client-side array is enough. For a larger knowledge base, the next step is build-time index generation from versioned source files.

New MyZubster protocol records

We introduced a dedicated MyZubster domain:

MZ-001 — Knowledge Layer — canonical record protocol
MZ-002 — Evidence states — from collection to independent review
MZ-003 — Zorgax — AI assistance with human verification
MZ-004 — Development requests — turning patterns into testable work
MZ-005 — Circular economies — verified contribution model

These records capture the architecture behind the project:

AI assists with retrieval, structure and connections;
AI does not determine truth;
data integrity is not the same as scientific validity;
observed patterns can become scoped development requests;
digital evidence alone does not prove a physical-world outcome.

Circular economies and absorbent-product knowledge

We also added a new Circular economies domain:

AHP-001 — Circular Hygiene — evidence pilot framework
AHP-002 — Absorbent-product experience contribution model
AHP-003 — Absorbent materials — test and traceability template
AHP-004 — Circular economies — reproducible pilot catalogue

All are marked PROTOCOL.

This is intentional. They define ways to collect observations, trace materials and structure future tests. They do not claim that recycling performance, safety, comfort or environmental impact has already been independently validated.

A possible contribution path looks like this:

lived experience
→ documented observation
→ repeated pattern
→ DevelopmentRequest
→ prototype or research task
→ independent review

The important part is the boundary: user experience can guide product development without being misrepresented as clinical or scientific proof.

Deployment and validation

Before deployment, we checked the static JavaScript syntax:

node -e '
const fs = require("fs");
const source = fs.readFileSync("public/knowledge.html", "utf8");
const script = source.match(/<script>([\s\S]*?)<\/script>/)[1];
new Function(script);
console.log("JavaScript valid");
'

We then confirmed that the new canonical IDs existed in the file:

grep -n "MZ-001\|AHP-001\|Circular economies" public/knowledge.html

Finally, we created a timestamped backup and deployed through the existing Vercel project:

cp public/knowledge.html \
  "public/knowledge.html.bak.$(date +%F-%H%M%S)"

vercel --prod --yes --scope myzubster

What comes next

The current implementation is a practical static layer. The next technical steps are:

move records to Markdown files with YAML front matter;
validate record schemas in CI;
generate the domain index at build time;
add stable routes for individual records;
link records to sources, evidence and Development Requests;
add consent-aware contribution flows;
add independent review before any record is promoted to verified guidance.

Final thought

The goal is not to build another content directory.

The goal is to build a knowledge interface where uncertainty is visible, evidence is classified and contributions can evolve into testable work.

A static page is only the first layer. The real architecture is the discipline of not confusing a claim, an observation, an AI summary and a verified result.

Building Zorgax in Production: Hybrid AI Routing, Grounding, Fallbacks, and UX

Fri, 18 Sep 2026 15:05:04 +0000

Building Zorgax in Production: Hybrid AI Routing, Grounding, Fallbacks, and UX

Building an AI chatbot is easy.

Building an AI feature that survives production is a very different problem.

Over the last development cycle, we evolved Zorgax, the AI copilot inside MyZubster, from a simple conversational interface into a hybrid AI layer with model routing, cost controls, fallback logic, product grounding, runtime observability, and tighter integration with the rest of the platform.

The most interesting lesson was that the LLM API call ended up being one of the smallest parts of the system.

The goal

Zorgax is designed to act as the conversational entry point to MyZubster.

A user should be able to ask a normal question, explore the Marketplace, understand a LIFE Pilot, start a Seller journey, navigate the Metaverse, or receive guidance about the wider ecosystem.

But we did not want every request to go through the same AI model.

A simple message such as:

Ciao Zorgax

does not need the same infrastructure as:

Analyze the current LIFE workflow, evaluate KPI/MRV evidence,
and explain the deployment and repository architecture.

So we introduced a routing layer.

Hybrid model routing

The current architecture separates requests into broad standard and complex categories.

Research mode, long prompts, and signals related to coding, deployment, research, LIFE, KPI/MRV, automation, GitHub, or Vercel can move a request into the complex route.

Conceptually:

const tier =
useResearch ||
complexSignalCount >= 2 ||
text.length >= 2500

? "complex"
: "standard";

The architecture then becomes:

User
↓
Zorgax API
↓
Task classification
↓
AI Router
├── Standard → Ollama / general AI gateway
│
└── Complex / Research → OpenAI

                        ↓
                     fallback

This gives us a hybrid system instead of making the whole product dependent on one remote provider.

Making the model visible

One of the first improvements was exposing the actual route used by the backend.

The API returns metadata like:

{
"ai_provider": "openai",
"ai_model": "gpt-5.6-sol",
"ai_fallback_reason": null
}

The interface displays it directly below the response:

AI: OpenAI · gpt-5.6-sol

If something goes wrong:

AI: Ollama · qwen2.5:3b · fallback: openai_rate_limit

This looks like a small UI feature, but operationally it changes a lot.

We no longer have to ask:

Did OpenAI actually generate this answer?

The application tells us.

The first production surprise

Once OpenAI routing was enabled, the first production request did not succeed.

Zorgax returned a valid answer, but the logs showed:

aiProvider: ollama
aiModel: qwen2.5:3b
aiFallbackReason: openai_error

The OpenAI call had returned HTTP 429.

At first, that was not enough information.

A 429 can represent very different conditions: a temporary rate limit, exhausted API credits, a project spending limit, or another usage restriction.

So we improved the error handling rather than simply retrying blindly.

Precise OpenAI diagnostics

Zorgax now extracts safe diagnostic information from failed requests:

HTTP status
error code
error type
request id

without exposing credentials.

Fallback states can now be much more precise:

openai_credit_balance_exhausted
openai_rate_limit
openai_rate_limit_exceeded
openai_project_spend_limit_exceeded

That immediately paid off.

Our next production test returned:

openai_credit_balance_exhausted

The application was working correctly. The account simply had no API credit.

After adding credit, the next request succeeded with:

AI: OpenAI · gpt-5.6-sol

and production logs confirmed:

aiProvider: openai
aiModel: gpt-5.6-sol
aiFallbackReason: null

That was the first full end-to-end verification.

Retry without retrying everything forever

Transient failures still need resilience.

For rate-limit-style failures, Zorgax now has controlled retry behavior.

The primary route can retry once, respecting Retry-After when the wait is short enough. A secondary OpenAI model can then be attempted before the system falls back to the local/general route.

The flow is roughly:

gpt-5.6-sol

↓

controlled retry

↓

secondary OpenAI model

↓

Ollama fallback

Quota errors are different.

If the API explicitly says credits are exhausted, retrying repeatedly would only waste time, so the fallback happens immediately.

That distinction is important: resilience does not mean retrying every failure.

Cost controls belong in the architecture

Remote AI usage also needs application-level cost controls.

Before sending a complex request, Zorgax checks its monthly OpenAI budget and reserves enough capacity for the request.

The flow looks like this:

Classify request

↓

Check monthly spend

↓

Estimate request cost

↓

Reserve budget

↓

Call OpenAI

↓

Record actual usage

↓

Settle reservation

If the reservation cannot be made, the conversation can continue through the fallback path.

We also record the model that actually completed the request, so usage accounting still makes sense if a secondary OpenAI model is used.

Grounding became the harder problem

Once OpenAI was running correctly, another issue appeared.

The model became too conservative.

We asked Zorgax which MyZubster features were live, experimental, planned, or unverified.

The answer classified nearly everything as unverified.

That was technically cautious, but it was also wrong.

The reason was architectural: the OpenAI route and the Ollama route were not receiving exactly the same runtime product context.

The local route had product facts.

The OpenAI route mostly had the system persona and the user message.

So instead of weakening our anti-hallucination rules, we fixed the input architecture.

One canonical runtime context

Both model paths now receive the same canonical product context.

It includes facts such as:

myzubster.com is live

/marketplace is an implemented route

Seller starts from Marketplace

/social-login is the authentication path

/metaverse is an implemented route

/life-pilot is an implemented pilot path

MYZ is internal reward/accounting

It also contains an important rule:

A live route does not prove every possible feature associated with that route.

That distinction prevents two opposite failures.

The assistant should not invent features that do not exist, but it should also not deny the existence of routes that are actually implemented.

Product state as part of the prompt

Zorgax now reasons with four capability states:

LIVE / IMPLEMENTED
PILOT / EXPERIMENTAL
PROPOSED / PLANNED
UNKNOWN / UNVERIFIED

For example, /metaverse being live means the route exists.

It does not automatically mean Sellers can create virtual stores.

Likewise, /life-pilot being live does not prove that GPS field reporting, scientific validation, public map publication, or environmental measurements are all implemented.

After introducing the shared runtime context, the same test produced a much better result.

Marketplace, Seller flow, authentication, Metaverse, LIFE Pilot, open-source contribution, and MYZ were described according to their verified status, while advanced dashboards, IoT integrations, IPFS/IPNS workflows, and external settlement remained unverified.

And this time the answer was generated by:

AI: OpenAI · gpt-5.6-sol
The chat itself needed work too

Backend architecture was only half the problem.

The original Zorgax interface had a very small conversation area.

Long AI answers appeared with the scroll position close to the end of the response, forcing the user to scroll upward to begin reading.

We changed the page so that the conversation became the main content area.

New assistant replies are now positioned at the beginning of the new response rather than the end.

The scroll logic is roughly:

function scrollMessageToTop(element) {
const delta =

element.getBoundingClientRect().top -
messages.getBoundingClientRect().top;

messages.scrollTo({

top: messages.scrollTop + delta - 12,
behavior: "smooth"

});
}

We also prevent textarea focus from modifying the viewport:

input.focus({ preventScroll: true });

This made long-form AI responses dramatically easier to read.

Zorgax also needed an exit

There was one more product problem.

Once a user entered Zorgax, the assistant page felt too isolated from the rest of MyZubster.

A product copilot should help users move through the product, not trap them inside the AI interface.

So we added permanent navigation in the Zorgax header:

🏠 Home MyZubster
🛒 Marketplace

The page also contains guided actions for Seller, Marketplace, Metaverse, LIFE Pilot, University/research, Community, and other supported journeys.

This turned Zorgax from a standalone AI page into a real navigation layer for the wider product.

Observability closed the loop

Vercel runtime logging now gives us a compact record of every AI routing decision.

A successful production event can look like:

event: zorgax_message_sent
plan: pro
webResearch: true
sourceCount: 0
aiProvider: openai
aiModel: gpt-5.6-sol
aiFallbackReason: null

During debugging, this was one of the most valuable pieces of the system.

Without it, an answer that looked fine could still have silently come from the fallback model.

With it, we can trace the actual production path.

What the architecture looks like now

The current system can be summarized like this:

User
↓
Zorgax UI
↓
Access policy
↓
Optional research
↓
Task classification
↓
Canonical product context
↓
AI Router
├── OpenAI
│ ├── primary model
│ ├── controlled retry
│ └── secondary model
│
└── Ollama / general AI fallback
↓
Grounded answer
↓
Provider + model metadata
↓
Runtime logs
↓
User

That is much closer to an AI product architecture than a simple chatbot.

What we learned

The LLM call was the easy part.

The actual production system is:

model

routing
budget controls
retry policy
fallbacks
grounding
authorization
observability
UI
navigation

The more capable an AI model becomes, the more important it is for the application around it to define what is real.

The application has to know:

what exists
what is experimental
what is verified
what the AI may do
what actually happened

That is the direction we are taking with Zorgax and MyZubster.

AI can reason.

The product still owns truth, permissions, evidence, and execution.

We did not come to conquer. We came to build together.

Per CoderLegion userei come titolo:

Building Zorgax in Production: Hybrid AI Routing, Grounding, Fallbacks, and UX

Come sottotitolo:

How we evolved the MyZubster assistant from a chat interface into an observable, budget-aware, multi-model product copilot.

# Building a Serverless-Safe Realtime Metaverse for MyZubster

Tue, 01 Sep 2026 09:31:49 +0000

Building a Serverless-Safe Realtime Metaverse for MyZubster

We have completed a major infrastructure upgrade for MyZubster World.

The original realtime system used Server-Sent Events and in-memory state. It worked locally, but serverless deployments introduced a problem: different requests could reach different Vercel instances, each with its own memory.

The result? Players could join successfully while the interface remained stuck on RECONNECTING.

What we changed

We moved the shared Metaverse state to MongoDB.

The new architecture supports:

shared player presence across serverless instances;
synchronized movements and emotes;
recent shared chat messages;
automatic expiration of inactive sessions with TTL indexes;
resilient browser synchronization;
automatic recovery after temporary connection failures;
verified MyZubster characters linked to authenticated accounts;
clear separation between verified users and guests.

The React frontend now periodically calls:

POST /api/metaverse/sync
Each synchronization refreshes the session and returns the current players, movements, emotes, and new chat messages.
This replaces the fragile dependency on a long-lived EventSource connection.
Verified identity
Authenticated users enter with the character linked by the server to their MyZubster account.
Browser-supplied names and identifiers cannot override a verified identity.
For example, the character H4x0r is displayed as:
H4x0r
@DanielIoni-creator
MYZ VERIFIED
Guests can still explore the world, but they are clearly marked as guests.
Production results
The implementation was successfully deployed and verified:
- Vercel deployment: ready;
- world API: HTTP 200;
- active transport: shared-polling;
- MongoDB shared presence: operational;
- legacy Metaverse EventSource removed from the frontend;
- 11 automated tests passed.
This architecture gives MyZubster a reliable serverless foundation today while keeping the door open for WebSockets, Redis, or a dedicated realtime network in the future.
Explore MyZubster World:
🌍 https://www.myzubster.com/metaverse
View the implementation:
💻 https://github.com/MyZubster-Ecosystem/myzubster/commit/412babfedfe29a917e5c6802c34defdcbfad75e7
What approach do you prefer for realtime serverless applications: polling, WebSockets, Redis streams, or an external realtime provider?
#MyZubster #OpenSource #Metaverse #ReactJS #NodeJS #MongoDB #Serverless #WebDevelopment #Realtime #Vercel

How to Deploy Your Website for Free (Vercel, Netlify, GitHub Pages)

Fri, 14 Aug 2026 05:00:00 +0000

Introduction

Building your first project is one milestone. Actually getting it live on the internet, with a real URL you can share, is a completely different feeling — and it used to be way more complicated than it is now.

Today, deploying a frontend project is genuinely a 5-minute job with the right platform. Here are the three most beginner-friendly options and exactly how to use each one.

Option 1: Vercel (Best for React/Next.js Projects)

Vercel is built by the creators of Next.js, and it's my personal go-to for React projects.

Steps:

Push your project to a GitHub repository (see Article 7 if you need a refresher)
Go to vercel.com and sign up with your GitHub account
Click "Add New Project"
Select your repository
Vercel auto-detects your framework (React, Next.js, Vite, etc.) and sets the build settings automatically
Click "Deploy"

That's it. Within a minute or two, you get a live URL like your-project.vercel.app.

Bonus: Every time you push new code to GitHub, Vercel automatically redeploys your site. No manual re-upload, ever.

Option 2: Netlify (Great All-Rounder)

Netlify works almost identically to Vercel and is equally beginner-friendly.

Steps:

Push your project to GitHub
Go to netlify.com and sign up with GitHub
Click "Add new site" → "Import an existing project"
Select your repository
Set your build command (for a Vite React app, this is usually npm run build) and publish directory (dist)
Click "Deploy site"

You'll get a URL like your-project.netlify.app, with the same automatic redeploy behavior on every push.

Netlify extra: It has a built-in drag-and-drop deploy option too — for a plain HTML/CSS/JS site with no build step, you can literally drag your project folder into the browser and it goes live instantly.

Option 3: GitHub Pages (Simplest for Static Sites)

GitHub Pages is a solid choice for portfolio sites and static HTML/CSS/JS projects — it's what many developers use for their own portfolio (mine included).

Steps for a React (Vite) project:

Install the gh-pages package:

npm install gh-pages --save-dev

In package.json, add:

"homepage": "https://yourusername.github.io/your-repo-name",
"scripts": {
  "predeploy": "npm run build",
  "deploy": "gh-pages -d dist"
}

Run:

npm run deploy

In your GitHub repo settings, go to Pages and confirm the source is set to the gh-pages branch.

Your site goes live at yourusername.github.io/your-repo-name.

For a plain HTML/CSS/JS project (no build step):

Just push your files to GitHub, go to Settings → Pages, select your main branch as the source, and save. Done.

Vercel — Best for React and Next.js projects. Offers a free custom domain.
Netlify — Best for any frontend framework, with built-in form handling and serverless functions. Offers a free custom domain.
GitHub Pages — Best for simple static websites and portfolios. Supports a free custom domain with a little setup.

My honest recommendation: use Vercel or Netlify for client and freelance projects — they handle builds, environment variables, and redeploys more smoothly. Use GitHub Pages for personal portfolio projects where simplicity matters more than advanced features.

Common Beginner Mistakes

Forgetting to set the correct build/publish directory. For Vite projects, it's dist. For Create React App, it's build. Get this wrong and you'll see a blank page.
Hardcoding API keys directly in your code instead of using environment variables — both Vercel and Netlify let you set these securely in project settings.
Not testing the production build locally first. Run npm run build and npm run preview (Vite) before deploying, to catch build errors early.
Forgetting the homepage field for GitHub Pages — without it, your assets (CSS, images) often break after deployment.

Final Thoughts

There's no excuse to keep a finished project sitting only on your local machine anymore. Pick Vercel or Netlify, connect your GitHub repo, and you'll have a shareable, live link in minutes — something you can put directly in a portfolio, a Fiverr gig, or a job application.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

Excited to Share My Latest Full-Stack Project: NeighborHelp! 🤝

Wed, 29 Jul 2026 06:12:56 +0000

Have you ever been in a situation where you needed immediate help from someone nearby?

Maybe you needed a blood donor, a local electrician, emergency transportation, pet care, or just someone in your neighborhood who could help quickly.

Finding the right person at the right time isn't always easy.

That's exactly why I built NeighborHelp — a modern community platform that helps people connect with nearby neighbors and provide or receive help in real time.

🌐 Live Demo:
https://neighborhelp99.vercel.app

💡 What Makes NeighborHelp Special?

📍 Smart Location-Based Help

NeighborHelp uses real-time location to show nearby help requests with distance filters like:

Within 5 km
Within 10 km
Within 25 km
Anywhere

This makes finding nearby help simple and fast.

💬 Real-Time Chat

Users can instantly communicate using a built-in chat system powered by Socket.io.

Features include:

Online status
Live typing indicators
Instant messaging

Everything updates in real time without refreshing the page.

🔔 Instant Notifications

Urgent requests shouldn't wait.

NeighborHelp instantly sends:

Web Push Notifications
Automated Email Alerts

so people can respond as quickly as possible.

🏆 Community Reputation System

Helping others deserves recognition.

The platform includes:

10-level badge system
Reputation points
Community success stories

to encourage active participation and build trust.

🤖 NeighborBot AI Assistant

An integrated AI assistant helps users by:

Answering common questions
Guiding new users
Suggesting helpful actions
Making the platform easier to use

🛡️ Secure Authentication

Security was one of my top priorities while building this project.

Features include:

JWT Authentication
Express Rate Limiting
OTP-based Password Recovery
Protected APIs

🛠️ Tech Stack

Frontend

Next.js 16
React
Tailwind CSS
Vanilla CSS

Backend

Node.js
Express.js
Socket.io
Web Push API

Database & Deployment

Supabase PostgreSQL
Vercel

💻 What I Learned

Building NeighborHelp from scratch helped me gain hands-on experience with:

Full-Stack Development
Real-Time Communication
AI Integration
Authentication & Security
Geolocation Services
Push Notifications
Database Design
Modern UI/UX

It was an exciting journey that pushed me to think beyond just writing code and focus on solving a real-world community problem.

❤️ I'd Love Your Feedback

If you have a few minutes, please check out the project and let me know what you think.

🌐 Live Demo:
https://neighborhelp99.vercel.app

Your feedback and suggestions will help me improve it even further.

Thank you for reading! 🚀

FullStackDevelopment #Nextjs #React #NodeJS #ExpressJS #SocketIO #Supabase #SoftwareEngineering #WebDevelopment #BuildInPublic #OpenSource #TechCommunity #SoftwareDeveloper

Best Hosting Platforms for Next.js in 2026: Who Actually Handles ISR & PPR Correctly?

Wed, 15 Jul 2026 10:05:54 +0000

Every "best hosting for Next.js" post you'll find says roughly the same thing: Vercel is great, Netlify is a solid alternative, Cloudflare is fast, AWS is for enterprises. None of them tell you what actually happens when you deploy a page using Incremental Static Regeneration (ISR) or Partial Prerendering (PPR) to platforms that aren't Vercel.

That's the gap this post fills. Instead of comparing dashboards and pricing pages, we're going to look at what each platform's adapter actually does with ISR and PPR — because "supported" doesn't mean the same thing everywhere. This article focuses on architecture and feature behavior rather than benchmark results, since latency varies significantly by region, workload, cache hit ratio, and deployment configuration.

The Distinction Nobody Explains: Functional vs. Performance Fidelity

This is the single most useful framing in this whole post, and it comes straight from Next.js's own platform documentation.

Tip: Next.js draws a line between two levels of platform support:

Functional fidelity — the feature works correctly. Your ISR page revalidates, your PPR shell renders.

Performance fidelity — the feature works optimally. The static shell is served from the CDN edge in milliseconds, not from a server function in another region.

A platform can have full functional fidelity for PPR (it renders correctly) while having much lower performance fidelity than Vercel (it's served from a function instead of true edge-cached HTML). Both are "PPR support" — but they perform very differently in production. Keep this distinction in mind for every platform below.

Why ISR and PPR Are Hard for Non-Vercel Platforms

Quick recap if you need it: ISR lets a static page revalidate itself in the background after a set time, without a full rebuild. PPR (the rendering mode behind Cache Components, Next.js's "use cache" model) splits a single page into a static shell plus dynamic "holes" that stream in separately.

Both features assume something most CDNs weren't built for: that cached HTML can be mutated after deployment — purged, regenerated, and partially streamed — rather than treated as an immutable file tied to one deploy. Traditional CDN deploy models (Netlify, Cloudflare Pages, AWS Amplify, and others all once worked this way) assume deployed assets never change until the next deploy. ISR and PPR break that assumption on purpose.

This is exactly why Next.js, Netlify, Cloudflare, AWS Amplify, and Google Cloud spent over a year building a shared Deployment Adapter API, which went stable in Next.js 16.2 (March 2026). Before this, most non-Vercel platforms were reverse-engineering Vercel's undocumented internal build output to support ISR at all. Now there's a public, versioned contract every platform builds against — including Vercel itself.

That context matters because it means platform support for these features is improving rapidly and consistently right now, not stagnant.

Platform-by-Platform Breakdown

Vercel

Vercel built Next.js, so unsurprisingly it has both full functional and the highest performance fidelity for ISR and PPR.

ISR: Native. Stale content serves instantly while regeneration happens in the background, with sub-second revalidation propagation across their edge network.
PPR / Cache Components: This is where the gap is biggest. PPR's design intentionally splits a response into a CDN-cacheable static shell plus a dynamically-stitched stream appended at request time. As of this writing, Vercel is the only platform that stitches that static shell and the dynamic stream together at the CDN edge itself — every other platform currently resolves PPR through a server/function layer instead of true edge stitching.

// app/products/[id]/page.tsx — works identically everywhere,
// but only Vercel currently serves the static part from true edge cache
async function getProduct(id: string) {
  "use cache";
  const res = await fetch(`https://api.example.com/products/${id}`);
  return res.json();
}

Best for: teams who want zero deployment-config overhead and the fastest possible PPR/ISR performance out of the box, and don't mind paying for that convenience.

⚠️ Common Mistake: Assuming Vercel's free Hobby tier scales like its paid tier. Function execution time, image optimization, and bandwidth all meter separately — a project that feels free in development can post a real bill in production.

Netlify

Netlify's Next.js Runtime is an officially maintained adapter, tested against every new stable Next.js release.

ISR: Fully supported, including both time-based and on-demand revalidation, via Netlify's fine-grained caching primitives for the Full Route Cache and Data Cache.
PPR: Supported — Netlify provisions a serverless Function specifically to handle SSR, ISR, and PPR. This gives full functional fidelity, but the static shell isn't served straight from CDN edge cache the way Vercel's is — it still runs through that Function layer, which is the performance-fidelity gap described above.

// next.config.ts — no Netlify-specific config needed for PPR itself,
// the adapter detects and provisions the right Functions automatically
const nextConfig = {
  cacheComponents: true,
};

Best for: teams who want Vercel-like functional completeness with a different pricing model or existing Netlify infrastructure (Forms, Identity, etc.).

⚠️ Common Mistake: Pointing Next.js rewrites at static files inside public/ — Netlify's adapter doesn't support that pattern, so routes that worked locally can silently 404 in production.

Cloudflare Workers (via OpenNext)

Cloudflare doesn't have a native Next.js runtime — you deploy through the community-maintained @opennextjs/cloudflare adapter, which transforms Next.js's build output into something Workers can run.

ISR: Supported through the adapter's caching layer.
PPR: Documented as supported for the App Router, but it's newer and still maturing — Cloudflare's own docs list PPR alongside features like Node Middleware as areas with ongoing compatibility work. A dedicated, verified Cloudflare adapter built on Next.js's new stable Adapter API is in active development, which should close most remaining gaps.
The catch: image optimization needs to be delegated to Cloudflare Images or configured separately — next/image doesn't work out of the box the way it does on Vercel.

# Cloudflare-specific deploy flow
npm install @opennextjs/cloudflare
npx @opennextjs/cloudflare
npx wrangler deploy

Best for: teams already invested in Cloudflare's edge network (Workers, D1, KV, R2) who want Next.js to live in the same ecosystem, and who can tolerate being slightly behind the bleeding edge on newer caching features.

⚠️ Common Mistake: Forgetting the nodejs_compat compatibility flag in wrangler.toml / wrangler.jsonc. Without it, plenty of Next.js server dependencies simply fail at runtime with confusing errors.

AWS Amplify

Amplify has supported Next.js SSR for a while, but it's noticeably behind on the newer caching model.

ISR: Time-based revalidation works. On-demand ISR (revalidatePath / revalidateTag triggered manually) is explicitly not supported — if your app relies on on-demand revalidation, it silently won't behave as expected on Amplify.
PPR / Cache Components: Not clearly documented as supported at the time of writing. Amplify's adapter has had open compatibility issues tracking Next.js 16 support, which suggests PPR support is still catching up rather than production-proven.
Build output is also capped at 220 MB for SSR apps — easy to hit with image-heavy or dependency-heavy projects.

Best for: teams already deep in AWS infrastructure (IAM, CloudFront, existing AWS billing) who need simple SSR + scheduled ISR, and who can verify PPR behavior thoroughly before relying on it in production.

⚠️ Common Mistake: Deploying with output: "export" and expecting ISR or SSR to work. Static export disables the Next.js server runtime entirely — no SSR, no ISR, no API routes, full stop.

Railway & Render (Container/Docker Platforms)

These two get grouped together because they take the same fundamental approach: you give them a Dockerfile or a Node process, and they run it. Functionally, this means ISR and PPR work exactly as well as they do in self-hosting — because that's effectively what's happening.

Railway: Has an official Next.js + Postgres deployment guide using output: "standalone" in a Dockerfile. SSR, SSG, and ISR all work as expected since it's a real persistent Node process. PPR isn't explicitly documented but should work for the same reason — it's just next start. The bigger concern reported in 2026 production usage isn't feature support, some users have reported reliability concerns around persistent storage and deployments, so production testing is important.
Render: Supports SSR, ISR, and API routes through its Web Service deployment type, also via Docker or Git-based builds. Same story as Railway — because it's a real Node process, feature support isn't the limiting factor. Zero-downtime rolling deploys need deliberate configuration; they're not automatic the way they are on Vercel.

Best for: teams who want container-based pricing predictability without writing their own Dockerfile-to-production pipeline from scratch, and who are comfortable being early on platform maturity.

⚠️ Common Mistake: Treating Railway or Render as "set and forget" the way Vercel is. Both still require you to think about zero-downtime deploys, shared cache for multiple instances, and monitoring — that operational layer doesn't disappear just because there's no explicit Next.js adapter to configure.

Self-Hosting (Docker, VPS, Fly.io, Cloud Run)

This is the one with the cleanest answer of all of them, straight from Next.js's own documentation:

A single next start process handles every Next.js feature correctly: Server Components, ISR, PPR, Cache Components, Server Actions, Proxy, and after().

Full functional fidelity, no adapter, no caveats — because there's no translation layer between your app and the framework. The tradeoffs aren't about features; they're about who's doing the operational work.

# Minimal self-hosting Dockerfile
FROM node:22-alpine AS base
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM node:22-alpine AS runner
WORKDIR /app
COPY --from=base /app/.next/standalone ./
COPY --from=base /app/.next/static ./.next/static
EXPOSE 3000
CMD ["node", "server.js"]

What you give up is everything Vercel/Netlify automate for you:

Multi-instance cache coordination — if you scale beyond one server, revalidateTag() only invalidates the instance that handled the request by default. You need a shared cache handler (commonly Redis) so other instances learn about invalidations.
Streaming infrastructure — PPR's time-to-first-byte advantage depends on your reverse proxy actually supporting streaming responses. Without it, the static shell and dynamic content get buffered and sent together, which still works but quietly loses PPR's main benefit.
All the DevOps, full stop: TLS, zero-downtime deploys, observability, scaling rules.

Best for: teams with existing DevOps capacity, strict data residency or compliance requirements, or sustained traffic where Vercel's usage-based pricing starts to outpace flat compute costs.

⚠️ Common Mistake: Self-hosting without output: "standalone" in next.config.ts. Without it, your Docker image drags in the entire node_modules tree instead of a trimmed production bundle.

Quick Comparison

Platform	ISR (time-based)	ISR (on-demand)	PPR / Cache Components	Performance Fidelity
Vercel	✅ Native	✅ Native	✅ True edge-stitched shell	Highest
Netlify	✅ Via adapter	✅ Via adapter	✅ Via Function layer	High
Cloudflare Workers	✅ Via OpenNext	Maturing	Documented, still maturing	Medium
AWS Amplify	✅ Time-based only	❌ Not supported	Unclear / catching up	Medium-Low
Railway / Render	✅ (it's just Node)	✅ (it's just Node)	✅ (it's just Node)	Depends on your setup
Self-hosted	✅ Full fidelity	✅ Full fidelity	✅ Full fidelity	You configure it

So, Which One Should You Actually Use?

Default choice for most SaaS/MVP work: Vercel. The performance-fidelity gap on PPR is real, and for most projects, not having to think about adapters or streaming infrastructure is worth the premium.
Want Vercel-level functional support on a different platform or pricing model: Netlify is the most production-proven non-Vercel option for ISR and PPR today.
Already living in Cloudflare's ecosystem: Workers via OpenNext is viable, just confirm PPR behavior for your specific routes before launch — it's improving fast but newer than Netlify's support.
On AWS for compliance or org reasons: Amplify works for SSR + scheduled ISR; don't build a feature around on-demand revalidation or PPR there yet without testing thoroughly.
Want container simplicity without managing your own VPS: Railway or Render — but budget time for reliability testing, especially anything stateful.
Have DevOps capacity, compliance needs, or are past the point where usage-based pricing makes sense: self-host. Every feature works correctly by default; you're trading platform fees for engineering time.

Frequently Asked Questions

Does "supports ISR" mean it works exactly like Vercel?

Not necessarily. Use the functional vs. performance fidelity distinction from earlier in this post — most platforms now have functional support, but the experience (latency, edge caching, revalidation propagation speed) still varies.

Is PPR available everywhere yet?

Functionally, on most major platforms — yes. With the same performance characteristics as Vercel — no, not yet. Vercel currently has unique edge-stitching infrastructure that other platforms haven't replicated.

Will the new Adapter API make all platforms equal eventually?

It makes them correct against the same shared contract, which is a big deal for portability. It doesn't automatically make them equally fast — that still depends on each platform's own CDN and edge infrastructure investment.

Is self-hosting actually cheaper?

Compute usually is. Total cost isn't always — factor in the engineering hours for setup and ongoing maintenance, not just server bills, before assuming self-hosting wins on price.

Can I switch platforms later if I start with Vercel?

Yes, especially now that the Adapter API is stable and shared across platforms. It's not zero-effort, but it's far less risky than it was before this API existed.

Platform Migration Difficulty

Move From	Difficulty
Vercel → Netlify	Low
Vercel → OpenNext	Medium
Vercel → Self-hosted	Medium
Amplify → Vercel	Low

Wrapping Up

"Best Next.js hosting" isn't really a single ranking — it's a tradeoff between performance fidelity, pricing model, and how much operational work you want to own. Vercel still leads on PPR/ISR performance specifically because it built the rendering model the rest of the ecosystem is now catching up to. Everyone else is closing that gap at different speeds, and the new shared Adapter API is exactly why that gap is closing faster in 2026 than it ever has before.

If you're deploying something today: pick based on where your team already lives, then verify ISR/PPR behavior yourself in a staging deploy rather than trusting a docs page's checkmark — the distinction between "works" and "works well" is exactly what most comparison posts skip.

Useful Resources

Continue Learning

The Developer's Worst Nightmare: Vercel Has My Code, My Hard Drive Doesn't

Wed, 24 Jun 2026 17:08:53 +0000

We’ve all been there. A sudden laptop crash, an accidental rm -rf in the wrong directory, or a Git repository that somehow vanished into the ether. You look at your screen in horror, realizing your local source code is completely gone. But then you look at your browser tab—your website is still running perfectly fine on Vercel.

While Vercel is a hosting platform and not a cloud backup service, it is entirely possible to piece your project back together using what Vercel has cached. Here is the exact, strategic battle plan to recover your hard work based on how Vercel processes your deployments.

The Complications: What You Are Up Against
Before you start clicking around, you need to understand the limitations. Vercel does not store a neat, downloadable .zip file of your original local directory. When you deploy, Vercel takes your code, builds it, and distributes the compiled output.

The source code is heavily obfuscated and bundled: If you built a React, Next.js, or Vue app, Vercel compiles your readable components into giant, minimized JavaScript files.

The original server-side logic is hidden: Any API routes or server-side functions (like getServerSideProps or Node.js endpoints) are compiled into isolated AWS Lambda functions or Edge functions that you cannot easily read or download.

Asset fragmentation: While public assets like images and CSS are accessible, they are scattered across Vercel’s Content Delivery Network (CDN).

Missing environment variables: Your .env.local file was never uploaded to your Git provider, meaning secrets and API keys must be extracted manually from the Vercel dashboard.

The Recovery Strategy: Step-by-Step
Because we cannot just hit a "download source" button, we have to approach this problem dynamically based on what type of project you deployed.

Trigger Point 1: Leverage the Git History (Your Best Chance)
Even if your local machine wiped the repository, check the Vercel Dashboard under your project settings. Look at the connected Git repository link. If you deployed via GitHub, GitLab, or Bitbucket, the code still exists on their servers. All you need to do is run git clone [repository-url] on your new machine to get 100% of your source code back.

Trigger Point 2: Scrape the Source Maps via Developer Tools
If you deployed a frontend framework and accidentally deleted the remote Git repo too, you can use Source Maps. If you didn't disable them in your production build, open your live website, hit F12 to open Developer Tools, and navigate to the Sources or Debugger tab. If source maps are active, the browser reconstructs your exact original files (like App.jsx or index.tsx) right in front of you. You can literally copy and paste your original components back into a new folder.

Trigger Point 3: Pull Compiled Output via Vercel CLI
If the top two methods fail, you can use the Vercel Command Line Interface (CLI) to see what Vercel is holding onto. Open your terminal, log into your account using vercel login, and use the vercel project clone command or inspect the .vercel/output folder by running a local build check. While this mostly pulls down the built, static HTML/JS assets rather than your raw source code, it gives you the functional building blocks to reverse-engineer your layout.

Trigger Point 4: Salvage Your Environment Variables
A functional app needs its keys. Go to your Vercel Dashboard -> Project Settings -> Environment Variables. Vercel decrypts these for you on the dashboard. Copy these values immediately and save them into a new local .env file so your API connections don't break when you start rebuild attempts.

Moving Forward: Lock It Down
Once you have pieced your files back together, ensure this never happens again. Always back up your code upstream. Initialize a fresh Git repository immediately, push it to a secure cloud provider, and consider using a secondary cloud backup for your local machine's Documents or Developer folders.

Sumita
Web Developer

Back-End Web Development — VPS vs Vercel vs Netlify

Thu, 18 Jun 2026 03:34:03 +0000

Introduction

Every great web application with millions of users has an even greater back end — and it has to be. Accessing your app over a prolonged period of time will test the integrity, availability, and speed of your back end. Backend technology can be inexpensive, or it can cost you thousands of dollars. So what's the deal here?

Let me warn you that this post is highly opinionated. I am sharing the tools that I use and how I use them.

For my back end that powers my web apps, I use Directus for my headless CMS, supported by a PostgreSQL and Redis database, hosted on a VPS, and managed by Coolify. Wow, that is a mouthful — and on my channel I explore how they all work together.

So let's tackle each technology one at a time, starting with the VPS.

What is a VPS?

A Virtual Private Server, known as a VPS, is a virtual environment created on a physical server. Think of it like an apartment building — everyone shares the same physical structure, but each unit has its own private space, utilities, and security. While multiple VPS instances share a physical server, be careful not to confuse this with shared hosting.

Each VPS is allocated its own dedicated resources, which are restricted to that VPS for as long as it is active. Therefore, the performance of a VPS is not directly affected by the usage of other VPS instances, but rather by the underlying performance of the physical server itself.

What are the benefits of a VPS?

There are several benefits to consider when deciding on virtual private server hosting:

Greater control — Compared to shared hosting, you have root access and can fully customize your server environment.
Dedicated resources — Allocated CPU, memory, and storage help ensure consistent performance.
Scalability — You can easily scale resources up or down to accommodate changing traffic and application demands.
Cost-effectiveness — A VPS typically offers a balance between the affordability of shared hosting and the power of a dedicated server.
Improved security — Isolation from other users on the same physical server enhances security.
Choice of operating system — You can choose the operating system that best suits your needs, such as Linux or Windows.

How does it stack up against Vercel or Netlify?

Vercel offers minimal setup with Git integration and fast deployment right out of the box. It has a free Hobby plan, but it is strictly for personal, non-commercial use. Once your app grows and needs to scale, you will need to move to a paid plan.

The Pro plan starts at $20 per user per month, and also covers serverless functions. Despite the name, serverless code still runs on a physical server — however, the infrastructure management, such as scaling, security patching, and provisioning, is handled entirely by the cloud provider. The main factor to watch carefully is cost.

Vercel uses usage-based billing, and costs can escalate quickly — especially since Turbo build machines became the default for new Pro projects in February 2026, at 0.126USD per build minute. A moderate team workflow can generate over $400 per month in build costs alone, before bandwidth and compute charges. I have seen some alarming Vercel bills shared online by customers, which means you need to fully understand the pricing model before you commit.

Netlify has historically been more suited to static sites and composable web applications. Composable applications are software systems built from independent, interchangeable modules rather than a single rigid code base. Netlify also has Git integration, customizable build plugins, and serverless functions. Netlify moved to a credit-based pricing model in September 2025, which is
designed to simplify metered billing.

As of April 2026, the Pro plan costs 20USD per month and now includes unlimited team member seats, which is an improvement over the previous per-seat model. However, teams working on active projects with real traffic can burn through their credit allocation quickly, and credit pack add-ons at 10USD per 1,500 credits mean teams can regularly spend 40USD to 80USD or more per month beyond the base subscription. Your overall control is also more limited compared to a VPS, and you will still face a monthly cost as your app grows.

Now the VPS.

VPS prices can grow as your app grows, but in my experience at a slower and more predictable rate — with no surprise charges. However, if you manage a VPS yourself, it requires understanding web servers, firewalls, operating systems, caching, and more. It can get complex very quickly and may cause you to spend more time managing the server than building and scaling your app.

That is why some developers and business owners hire a team to handle it. Small teams may not have the budget for a dedicated infrastructure team, so they often opt for a more convenient managed solution.

There is one tool, however, that I think is worth mentioning and is a genuine game changer — and that is Coolify. In a later post I will go into more detail about what Coolify is and what it does. Coolify is a self-hostable platform that makes managing your VPS significantly easier. It offers Git integration, runs apps in Dockerized containers, handles HTTPS automatically, and includes a built-in web server that works out of the box with no manual configuration required. This makes the VPS a very real and competitive option worth considering.

If you choose a solid hosting provider and pair it with the right tools, you can make this an absolute dream to work with.

Now don’t get me wrong, even with Coolify there are some configurations that you will have to make, but I do believe a VPS is a great solution for a start up, mid-size or enterprise scaled app, with the right tools.

References

• https://cloud.google.com/learn/what-is-a-virtual-private-server 
• https://aws.amazon.com/what-is/vps/ 
• https://www.ibm.com/think/topics/vps 
• https://www.scalahosting.com/blog/what-is-a-vps-technical-explanation/ 
• https://www.dreamhost.com/blog/beginners-guide-vps/ 
• https://vercel.com/pricing 
• https://www.netlify.com/pricing/ 
• https://bejamas.com/blog/self-hosting-vs-vercel-and-netlify-which-solution-is-right

Growth Truth: Handling the Referral Spike

Wed, 15 Apr 2026 12:04:00 +0000

Growth Truth: Handling the Referral Spike

When traffic spikes, what breaks first — routing, LLM quotas, or database write paths? Here is how we framed a real referral window against a stateless chat surface.

Headline traffic (GA4)

Figures below are from Google Analytics 4 (Marketing performance) for a fixed 28-day window. GA4 can revise counts slightly as sessions reconcile; we cite the exported values for this slice.

Field	Value
Date range	2026-03-06 → 2026-04-02 (28 days)
Active users	4,669
New users	4,500

Two different dials: GA4 answers “how many people touched the property in this window.” Product-side analytics (referral events, campaign attribution, Stripe-adjacent rollups) answer “how did growth mechanics behave?” They are complementary, not interchangeable — and GA4 active users are not the same thing as Firebase Auth sign-in counts unless you say so explicitly.

Stateless inference and where burst load lands

The app’s chat path is stateless for portfolio payloads (/api/ai/chat — see Part 1). Under spike load, stress concentrates on:

Edge / routing — session affinity is not the model; referral survival is. We 307 apex → www so ?ref= and cookies stay coherent:

// middleware.ts — canonical host: apex → www
if (host === 'pocketportfolio.app') {
  url.hostname = 'www.pocketportfolio.app';
  return NextResponse.redirect(url, 307);
}

Serverless limits — maxDuration = 30 on the chat route; streaming responses; provider rate limits.
Firestore — quota counters (aiUsage), analytics metadata (toolUsage), referralEvents — hot writes, not giant prompt logs.

Takeaway: stateless inference keeps the heaviest sensitive payload off disk; growth still needs solid indexes and realistic capacity planning for referrals and quotas.

What tends to fail first

Referral attribution (middleware, cookies) — if this slips, growth looks “direct only.”
LLM provider throttling or streaming failures.
Firestore write contention on high-frequency collections during campaigns.

Part 4 of Sovereign Engineering.

Read the full Sovereign Intelligence book or try the app.

Getting Started with the Vercel AI SDK (Beginner to Working Chat App)

Wed, 21 Jan 2026 12:44:06 +0000

If you’re building AI features like chatbots, content generators, AI agents, or streaming assistants, you’ll quickly realize that the “LLM call” is only 20% of the work.

The other 80% is:
✅ streaming responses
✅ UI updates in real-time
✅ tool calling
✅ handling errors & retries
✅ server/client integration
✅ building a clean developer experience

That’s where the Vercel AI SDK shines.

In this blog, you’ll learn how to get started with the Vercel AI SDK and build a simple streaming chat app using Next.js.

What is the Vercel AI SDK?

The Vercel AI SDK is a set of libraries and utilities to build AI-powered apps with great UX:

Streaming responses (token-by-token)
React hooks for chat and completion
Easy server routes (Next.js App Router)
Tool/function calling support
Provider integrations (OpenAI, etc.)

It’s designed for modern full-stack apps, especially in the Next.js ecosystem.

What You’ll Build

By the end, you’ll have:

✅ A Next.js app
✅ A chat UI
✅ An API route that streams AI responses
✅ Working end-to-end in minutes

Step 1: Create a Next.js App

Run:

npx create-next-app@latest vercel-ai-sdk-demo
cd vercel-ai-sdk-demo
npm run dev

Choose:

TypeScript ✅
App Router ✅
Tailwind (optional but recommended) ✅

Step 2: Install the Vercel AI SDK

Install the SDK:

npm install ai

Then install an AI provider package (OpenAI is common):

npm install @ai-sdk/openai

Step 3: Add Your API Key

Create .env.local:

OPENAI_API_KEY=your_api_key_here

Restart the dev server after adding env vars.

Step 4: Create the Streaming Chat API Route

In Next.js App Router, create:

app/api/chat/route.ts

import { openai } from "@ai-sdk/openai";
import { streamText } from "ai";

export async function POST(req: Request) {
  const { messages } = await req.json();

  const result = await streamText({
    model: openai("gpt-4o-mini"),
    messages,
    system: "You are a helpful assistant. Keep answers short and clear.",
  });

  return result.toDataStreamResponse();
}

What’s happening here?

messages contains the full chat history
streamText() streams the model output
toDataStreamResponse() returns a streaming response to the UI

Step 5: Build the Chat UI with `useChat()`

Now create a UI page:

app/page.tsx

"use client";

import { useChat } from "ai/react";

export default function Home() {
  const { messages, input, handleInputChange, handleSubmit, isLoading } =
    useChat({ api: "/api/chat" });

  return (
    <main style={{ maxWidth: 700, margin: "40px auto", padding: 16 }}>
      <h1 style={{ fontSize: 24, fontWeight: 700 }}>Vercel AI SDK Chat</h1>

      <div style={{ marginTop: 20, border: "1px solid #ddd", padding: 16 }}>
        {messages.map((m) => (
          <div key={m.id} style={{ marginBottom: 12 }}>
            <strong>{m.role}:</strong> {m.content}
          </div>
        ))}
      </div>

      <form onSubmit={handleSubmit} style={{ marginTop: 16, display: "flex" }}>
        <input
          value={input}
          onChange={handleInputChange}
          placeholder="Ask something..."
          style={{ flex: 1, padding: 10, border: "1px solid #ccc" }}
        />
        <button
          type="submit"
          disabled={isLoading}
          style={{ marginLeft: 8, padding: "10px 14px" }}
        >
          Send
        </button>
      </form>
    </main>
  );
}

Step 6: Run It

Start your app:

npm run dev

Open:
http://localhost:3000

Now type a message and watch the AI respond in real-time.

Understanding `messages`

messages is an array like:

[
  { role: "user", content: "Hello" },
  { role: "assistant", content: "Hi! How can I help?" }
]

The SDK manages:

appending new messages
streaming assistant messages
updating UI automatically

Add a Better UI (Optional)

You can style messages by role:

{messages.map((m) => (
  <div
    key={m.id}
    style={{
      padding: 12,
      borderRadius: 12,
      marginBottom: 10,
      background: m.role === "user" ? "#f2f2f2" : "#e7f5ff",
    }}
  >
    <strong>{m.role}:</strong> {m.content}
  </div>
))}

Bonus: Add Tool Calling (Basic Example)

Tool calling allows your AI to call functions like:

search database
fetch weather
calculate tax
call APIs

Example concept:

tools: {
  getTime: {
    description: "Get current server time",
    execute: async () => new Date().toISOString(),
  },
}

This is where Vercel AI SDK becomes powerful for agentic workflows.

Common Issues & Fixes

❌ “OPENAI_API_KEY missing”

Fix:

Ensure .env.local exists
Restart dev server
Check variable name

❌ No streaming happens

Fix:

Use useChat() properly
Ensure API route returns toDataStreamResponse()

❌ Build fails on deployment

Fix:

Add env var in Vercel dashboard
Ensure route uses server runtime properly

Production Tips (Best Practices)

✅ Keep prompts stable

Use a clear system prompt and avoid changing it too often.

✅ Limit message history

For performance, send only last N messages.

✅ Add safety

Filter harmful content or enforce policies.

✅ Add logging

Log prompts, latency, and tool usage.

What to Build Next

Once you have a basic chat working, you can extend it into:

AI Customer Support Assistant
RAG-powered Knowledge Bot
AI Agent for Jira / GitHub tasks
Meeting Summary Generator
AI Form Auto-Fill Assistant

Conclusion

The Vercel AI SDK is one of the fastest ways to build AI apps with excellent streaming UX and clean developer experience.

If you’re building in Next.js, this is a must-try toolkit.

Note: Create agents using Vercel
https://emilyxiong.medium.com/create-an-ai-agent-with-vercel-ai-sdk-e690b807eb2a

Deploy your application on Vercel with GitHub Actions

Wed, 20 Aug 2025 17:26:29 +0000

A very common CI/CD pattern for frontend apps is: build in CI and deploy to production automatically when the code reaches main.
If you use Vercel, you can do this with a short and reliable GitHub Actions workflow that:

downloads your project's configuration and variables from Vercel,
builds the app in CI,
and deploys the already built artifacts to production.

In this article, we'll walk through it step by step and I'll give you some tips to help you understand what each line does.

Purpose of the workflow

Every time there is a push to main, the following should be executed:

Pull config from Vercel (includes production environment variables).
Reproducible build in CI.
Deploy that artifact (without rebuilding in Vercel).

This will give you predictable deployments that are easy to audit and debug.

General workflow structure

name: Vercel PRO deployment
on:
  push:
    branches:
      - main
jobs:
  deploy:
    name: deploy
    runs-on: ubuntu-latest
    steps:
      - id: checkout-step
        name: Checkout code
        uses: actions/checkout@v4
      - id: install-vercel-cli-step
        name: Install Vercel CLI
        run: npm install --global vercel@latest
      - id: pull-vercel-env-info-step
        name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN
          }}
      - id: build-vercel-artifacts-step
        name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - id: deploy-vercel-artifacts-step
        name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

Prerequisites
Create the secret VERCEL_TOKEN in your repository (Settings → Secrets and variables → Actions).
Either commit .vercel/project.json, or provide VERCEL_ORG_ID and VERCEL_PROJECT_ID as secrets when you do vercel pull.

Step by step

on: push (to main)
Each push to main triggers the production pipeline. If you prefer to only deploy when merging by PR, simply avoid pushing directly to main.

uses: actions/checkout@v4
Download your code to the runner so that the following tools (Vercel CLI) have it available.

npm install --global vercel@latest
Install the Vercel CLI.

Tip: to avoid surprises, you can set version: vercel@xx (or whatever you use on your team).

vercel pull --yes --environment=production
Bring the project configuration and production environment variables to .vercel/ on the runner.
In CI there are no interactive questions, so we use --yes.

You need:

.vercel/project.json in the repository or
VERCEL_ORG_ID and VERCEL_PROJECT_ID as variables/secrets.

vercel build --prod
Builds in CI using your framework (Next.js, SvelteKit, etc.) or what is defined in vercel.json.
The result is stored in .vercel/output and is exactly what you are going to deploy.

vercel deploy --prebuilt --prod
Uploads the already built artifact to production.
With --prebuilt, Vercel does not rebuild: what you tested in CI is what your user will see.

✅ Final result

With this workflow, each merge to main runs a clean build and deploys that same artifact to production in Vercel. You get:

reproducible builds,
faster deploys,
and clear CI logs for debugging.

Prefer to configure it visually?

Writing workflows by hand gives you total control, but sometimes you want speed with built-in validations.

With OctoLab, you can set up this same pipeline visually: choose actions, fill in fields, and the YAML is generated instantly, ready to commit.

Try it out: https://www.octolab.app/templates/vercel-pro-deployment

Conclusion

This workflow provides you with a clean CI → production flow on every push to main, using Vercel's recommended approach: pull → build → deploy. It's easy to adapt to previews, monorepos, or strict reproducibility (fixed Node and CLI).

Use it as a base and evolve it with caching, notifications, or environment gates as your team grows.

Use your custom 404 component on Vercel — Easy Fix

Sun, 03 Aug 2025 22:33:07 +0000

I had just deployed a React application to Vercel, complete with routing and a custom 404 error page. I tested the live site in Vercel and tried visiting a non-existent route, but I couldn’t! Vercel’s default 404 page was rendered instead of my custom component.

Here’s how I fixed it

I needed to find a way to overwrite the default action by Vercel, so I conducted some research. So here’s what was happening - Vercel served its own 404 page before my React app loaded.

To fix this, first create a vercel.json file. Use the following code snippet in your file.

{
  "rewrites": [
    { "source": "/(.*)", "destination": "/" }
  ]
}

That was it! I redeployed the application, and now my 404 component was rendered instead of the default one from Vercel.

I hope this solution helped you. If so, please leave a comment below.

Thanks for reading, ciao

P.S. If your cursor starts acting up in VS Code, check out this article