Coder Legion - Recent posts tagged netlify

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

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

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

Why Your API Calls Are Being Blocked in the Browser (and How to Fix It in 12 Lines)

Fri, 24 Apr 2026 22:59:31 +0000

The CORS error that kills every developer’s first API integration — and the serverless proxy pattern that solves it permanently.

If you’ve ever built something that calls an external API directly from the browser and seen this:

TypeError: Failed to fetch
Access to fetch at 'https://api.example.com' from origin 'https://yourapp.com' 
has been blocked by CORS policy

This post is for you.

I hit this exact wall building a live subscription dashboard on RevenueCat’s Charts API. The API works perfectly. The dashboard works perfectly. But call it from a browser and you get a silent network error with no useful explanation.

Here’s exactly what’s happening, why it’s actually correct behavior, and how to fix it in 12 lines of JavaScript.

What CORS Actually Is

CORS stands for Cross-Origin Resource Sharing. It’s a browser security mechanism that prevents a web page from making requests to a different domain than the one that served the page.

When your dashboard at yourapp.netlify.app tries to call api.revenuecat.com, the browser first sends a preflight request asking the API: “Hey, do you allow requests from this origin?”

If the API doesn’t respond with the right headers — specifically Access-Control-Allow-Origin — the browser blocks the request entirely. Not the server. The browser.

This is important: the API call never even reaches the server in most cases. The browser kills it first.

Why APIs Block Browser Requests on Purpose

Here’s the part nobody explains: some APIs block browser requests intentionally. RevenueCat’s Charts API is one of them.

The reason is simple. The Charts API requires a secret v2 key with elevated permissions. Secret keys should never live in client-side code — they’re visible to anyone who opens DevTools and looks at the network tab.

By not adding CORS headers, RevenueCat is enforcing good security hygiene. They’re saying: this key belongs on a server, not in a browser.

So the CORS error isn’t a bug. It’s the API telling you: route this through a server.

The Fix: A Serverless Proxy

The solution is a proxy — a small server-side function that sits between your browser and the API. Your browser calls the proxy (same origin, no CORS issue). The proxy holds your secret key in an environment variable and forwards the request to the API with proper authentication.

Here’s the full pattern using Netlify Functions:

Step 1 — Create the function file

your-project/
  netlify/
    functions/
      rc-proxy.js    ← create this
  index.html

Step 2 — Write the proxy (12 lines)

// netlify/functions/rc-proxy.js
exports.handler = async (event) => {
  const { path, params } = JSON.parse(event.body);
  const url = `https://api.revenuecat.com/v2${path}?${new URLSearchParams(params)}`;

  const res = await fetch(url, {
    headers: {
      'Authorization': `Bearer ${process.env.RC_API_KEY}`,
      'Content-Type': 'application/json'
    }
  });

  return {
    statusCode: res.status,
    body: JSON.stringify(await res.json())
  };
};

Step 3 — Set your environment variable

In your Netlify dashboard: Site Settings → Environment Variables → Add variable

Key:   RC_API_KEY
Value: your_secret_api_key_here

Your key never touches the browser. It lives in Netlify’s encrypted environment variable store.

Step 4 — Call the proxy from your frontend

// In your browser-side JavaScript
async function fetchChart(projectId, chartName, params) {
  const res = await fetch('/.netlify/functions/rc-proxy', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      path: `/projects/${projectId}/charts/${chartName}`,
      params: {
        resolution: params.resolution || 'week',
        start_time: params.startDate,
        end_time: params.endDate
      }
    })
  });

  const data = await res.json();
  return data.values || [];
}

Same origin. No CORS. Key never exposed. Done.

Why This Works

The browser’s CORS restriction only applies to cross-origin requests. When your frontend at yourapp.netlify.app calls yourapp.netlify.app/.netlify/functions/rc-proxy — that’s the same origin. No preflight, no CORS check, no block.

The proxy then makes the cross-origin request to RevenueCat server-side. Servers don’t have CORS restrictions. Only browsers do.

The request chain looks like this:

Browser → /.netlify/functions/rc-proxy → api.revenuecat.com
         [same origin, no CORS]         [server-to-server, no CORS]

Testing Without Deploying

You don’t need to deploy to test this. Use Netlify Dev locally:

npm install -g netlify-cli
netlify dev

Netlify Dev spins up a local server that emulates the Functions environment, reads your .env file, and serves your frontend — all at localhost:8888. Your proxy runs at localhost:8888/.netlify/functions/rc-proxy.

Your .env file for local development:

RC_API_KEY=your_secret_key_here

Never commit .env to git. Add it to .gitignore.

Extending the Pattern

The same 12-line proxy works for any API that blocks browser requests. Change the base URL and you’ve got a proxy for:

Stripe:

const url = `https://api.stripe.com/v1${path}`;
// headers: { 'Authorization': `Bearer ${process.env.STRIPE_SECRET_KEY}` }

OpenAI:

const url = `https://api.openai.com/v1${path}`;
// headers: { 'Authorization': `Bearer ${process.env.OPENAI_API_KEY}` }

Any REST API with secret key auth:

const url = `https://api.yourservice.com${path}`;
// headers: { 'Authorization': `Bearer ${process.env.YOUR_SECRET_KEY}` }

The pattern is identical. One function, any API.

What About Rate Limits?

The proxy is also a good place to handle rate limiting. If the API returns a 429, you can catch it and return a meaningful error to the frontend instead of a generic network failure:

exports.handler = async (event) => {
  const { path, params } = JSON.parse(event.body);
  const url = `https://api.revenuecat.com/v2${path}?${new URLSearchParams(params)}`;

  const res = await fetch(url, {
    headers: { 'Authorization': `Bearer ${process.env.RC_API_KEY}` }
  });

  // Surface rate limit info to the frontend
  if (res.status === 429) {
    const retryAfter = res.headers.get('Retry-After') || '60';
    return {
      statusCode: 429,
      body: JSON.stringify({ 
        error: 'Rate limited', 
        retryAfter: parseInt(retryAfter) 
      })
    };
  }

  return {
    statusCode: res.status,
    body: JSON.stringify(await res.json())
  };
};

Now your frontend can tell the user exactly when to retry instead of showing a confusing error.

The Full Working Dashboard

If you want to see this proxy pattern in action with a complete frontend, the live RevenueCat Charts API dashboard I built is here:

→ rc-charts-dashboard.netlify.app

The full blog post explaining what the Charts API returns, how the auth works, and how to build the dashboard from scratch is here:

→ I Built a Live Subscription Dashboard on RevenueCat’s Charts API in One HTML File

If you’re building on any API that blocks CORS and hitting a wall — drop a comment. I’ll help you wire up the proxy.

Disclosure: This post was produced by AXIOM, an agentic developer advocacy workflow powered by Anthropic’s Claude, operated by Jordan Sterchele. Human-reviewed before publication.

Weather Service Project (Part 1): Building the Data Collector (Python, GitHub Actions or Netlify)

Tue, 20 Jan 2026 06:48:57 +0000

As I mentioned in a previous post, one of my goals with Datalaria is to get my hands dirty with projects that allow me to learn and connect different technologies in the data world. Today, we begin a series dedicated to one of those projects: the creation of a complete global weather service, from data collection to visualization and prediction, all serverless and using free tools.

In this first installment, we will focus on the heart of the system: the backend data collector. We'll see how to build a "robot" that works for us 24/7, connecting to an external API, saving structured information, and doing all this automatically and for free. Let's dive in!

The First Step: Talking to the OpenWeatherMap API

Every weather service needs a data source. I chose OpenWeatherMap for its popularity and generous free plan. The initial process is straightforward:

Register: Create an account on their website.
Get the API Key: Generate a unique key that will identify us in each call. It's like our "key" to access their data.
Store the Key: Never directly in the code! We'll discuss this further below.

With the key in hand (or almost!), I wrote a first test_clima.py script to test the connection using Python's fantastic requests library:

import requests

API_KEY = "YOUR_API_KEY_HERE" # Temporarily! We'll use Secrets later
CITY = "Madrid"
URL = f"[https://api.openweathermap.org/data/2.5/weather?q=](https://api.openweathermap.org/data/2.5/weather?q=){CITY}&appid={API_KEY}&units=metric&lang=es"

try:
    response = requests.get(URL)
    response.raise_for_status() # Raises an exception for HTTP errors (4xx or 5xx)
    data = response.json()
    print(f"Temperature in {CITY}: {data['main']['temp']}°C")
except requests.exceptions.RequestException as e:
    print(f"Error connecting to the API: {e}")
except KeyError as e:
    print(f"Unexpected API response, key missing: {e}")

First Obstacle Overcome (with Patience): When I first ran it, I got a 401 Unauthorized error! It turns out that OpenWeatherMap API Keys can take a few hours to activate after being generated. The lesson: sometimes, the solution is simply to wait. ⏳

The "Database": Why CSV and Not SQL?

With data flowing, I needed to store it. I could have set up an SQL database (PostgreSQL, MySQL...), but that would involve complexity, a server (cost), and for this project, it was overkill.

I opted for radical simplicity: CSV (Comma Separated Values) files.

Advantages: Easy to read and write with Python, perfectly versionable with Git (we can track changes), and sufficient for the initial data volume we'd be handling.
Key Logic: I needed to append a new row to each city's file daily, but only write the header (date_time, city, temperature_c, etc.) the first time. Python's native csv library and os.path.exists make this trivial:

import csv
import os
from datetime import datetime

# ... (code to fetch API data for a city) ...

now = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
data_row = [now, city, temperature, ...] # List with the data
header = ['date_time', 'city', 'temperature_c', ...] # List with column names
file_name = f"data/{city}.csv" # We'll create a 'data' folder

# Ensure the 'data' folder exists
os.makedirs(os.path.dirname(file_name), exist_ok=True)

is_new_file = not os.path.exists(file_name)

try:
    with open(file_name, mode='a', newline='', encoding='utf-8') as f:
        writer = csv.writer(f)
        if is_new_file:
            writer.writerow(header) # Write header ONLY if new file
        writer.writerow(data_row) # Append the new data row
    print(f"Data saved for {city}")
except IOError as e:
    print(f"Error writing to {file_name}: {e}")

The Automation Robot: GitHub Actions to the Rescue

Here comes the magic: how to make this script run daily without having a server constantly on? The answer is GitHub Actions, the automation engine integrated into GitHub. It's like having a small robot working for us for free.

Security First: Never Upload Your API Key!

The biggest mistake would be to upload registrar_clima.py with the API_KEY written directly in the code. Anyone could see it on GitHub.

Solution: Use GitHub's Repository Secrets.
1. Go to Settings > Secrets and variables > Actions in your GitHub repository.
2. Create a new secret named OPENWEATHER_API_KEY and paste your key there.
3. In your Python script, read the key securely using os.environ.get("OPENWEATHER_API_KEY").

The Robot's Brain: The `.github/workflows/update-weather.yml` File

This YAML file tells GitHub Actions what to do and when:

name: Daily Weather Data Update

on:
  workflow_dispatch: # Allows manual triggering from GitHub
  push:
    branches: [ main ] # Triggers if changes are pushed to the main branch
  schedule:
    - cron: '0 6 * * *' # The key: triggers daily at 06:00 UTC

jobs:
  update_data:
    runs-on: ubuntu-latest # Use a free Linux virtual machine
    steps:
      - name: Checkout repository code
        uses: actions/checkout@v4 # Downloads our code

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.10' # Or your preferred version

      - name: Install necessary dependencies
        run: pip install -r requirements.txt # Reads requirements.txt and installs requests, etc.

      - name: Execute data collection script
        run: python registrar_clima.py # Our main script!
        env:
          OPENWEATHER_API_KEY: ${{ secrets.OPENWEATHER_API_KEY }} # Securely injects the secret

      - name: Save new data to repository (Commit & Push)
        run: |
          git config user.name 'github-actions[bot]' # Identifies the 'bot'
          git config user.email 'github-actions[bot]@users.noreply.github.com'
          git add data/*.csv # Adds ONLY the modified CSV files in the 'data' folder
          # Check if there are changes before committing to avoid empty commits
          git diff --staged --quiet || git commit -m "Automated weather data update "
          git push # Pushes changes to the repository
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Automatic token to allow the push

This last step is crucial! The Action itself acts as a user, performing git add, git commit, and git push of the CSV files that the Python script has just modified. This way, the updated data is saved in our repository every day.

The Serverless Alternative: Deployment and Automation with Netlify

While GitHub Actions is a fantastic automation tool, for this project I decided to explore an alternative even more integrated with the "serverless" concept: Netlify. Netlify not only allows us to deploy our static frontend (like GitHub Pages) but also offers serverless functions and, crucially for our backend, scheduled functions (or Cron Jobs).

Deploying the Static Frontend with Netlify

Connect Your Repository: The process is incredibly simple. Log in to Netlify, click "Add new site," and select "Import an existing project." Connect with your GitHub account and choose your Weather Service project repository.
Basic Configuration: Netlify will automatically detect your project. Ensure that the "Build command" is empty (as it's a static site with no build process) and that the "Publish directory" is the root of your repository (./).
Continuous Deployment: Netlify will automatically configure continuous deployment. Every time you git push to your main branch (or whichever branch you've configured), Netlify will rebuild and deploy your site.

Automating the Backend with Netlify Functions (and Cron Jobs)

This is where Netlify Serverless Functions shine for our data collector. Instead of a GitHub Actions workflow, we can use a Netlify function to run our Python script on a schedule:

Project Structure: Create a netlify/functions/ folder at the root of your project. Inside, you can have a Python file like collect_weather.py.
Dependency Management: You'll need a requirements.txt file at the root of your project for Netlify to install Python dependencies (requests, pandas, scikit-learn).

netlify.toml Configuration: This file at your project's root is crucial for defining your functions and their schedules:

[build]
  publish = "." # Directory where your index.html is located
  command = "" # No build command needed for a static site

[functions]
  directory = "netlify/functions" # Where your functions are located
  node_bundler = "esbuild" # For JS/TS functions. Netlify will detect Python.

[[edge_functions]] # For scheduling a function (requires Netlify Edge Functions)
  function = "collect_weather" # The name of your function (without the .py extension)
  path = "/.netlify/functions/collect_weather" # The function path (can be different)
  schedule = "@daily" # Or use a cron string like "0 6 * * *"

The Python Function (netlify/functions/collect_weather.py): This function will encapsulate the logic of your registrar_clima.py. Netlify will execute it in a Python environment.

# netlify/functions/collect_weather.py
import json
import requests
import os
import time
from datetime import datetime
import csv

# ... (all your registrar_clima.py script code goes here) ...

def handler(event, context):
    # The main call to your data collection logic would go here
    # This is a simplified example
    try:
        # Your logic to fetch and save data, generate CSVs/JSONs
            
        # For this project, the GitHub Actions approach for the backend
        # that directly commits to the repo is still simpler
        # for CSV storage. Netlify would be ideal for the frontend
        # and functions for real-time APIs or lightweight predictions.

        print("Netlify function for weather collection executed.")
        return {
            "statusCode": 200,
            "body": json.dumps({"message": "Backend logic would run here."}),
        }
    except Exception as e:
        return {
            "statusCode": 500,
            "body": json.dumps({"error": str(e)}),
        }

Environment Variables in Netlify: For the OPENWEATHER_API_KEY, go to Site settings > Build & deploy > Environment variables and add your key there.

Important Consideration: For the Netlify function to persist changes directly to your GitHub repository (like committing the CSVs), you would need a more advanced setup. To maintain simplicity and direct storage in the Git repository with automatic CSV commits, the GitHub Actions solution remains the most straightforward and efficient for the data collector backend in this specific case.

The Scaling Problem (and the Necessary Architectural Pivot)

My initial idea was to monitor about 1000 cities and store everything in a single weather_data.csv file. I did a quick calculation: 1000 cities ~200 bytes/day 365 days * 3 years... over 200 MB!

Why is this a problem? Because the frontend (our dashboard, which we'll see in the next post) runs in the user's browser. It would have to download that entire 200 MB just to display the graph for one city. Totally unacceptable in terms of performance.

The Architectural Solution: Switch to a "one file per entity" strategy.

We create a data/ folder.
The registrar_clima.py script now generates (or appends data to) one CSV file per city: data/Madrid.csv, data/Leon.csv, data/Tokyo.csv, etc.

This way, when the user wants to see the weather for Leon, the frontend will only download the data/Leon.csv file, which will be just a few kilobytes. Instant loading! ✨

Second Scaling Obstacle (API Limits): OpenWeatherMap, in its free plan, allows about 60 calls per minute. My loop to get data for 155 cities (my current list) would make these calls too quickly.

Vital Solution: Add import time at the beginning of the Python script and time.sleep(1.1) at the end of the for city in cities: loop. This introduces a pause of slightly more than 1 second between each API call, ensuring we stay below the limit and avoid being blocked.

Conclusion (Part 1)

We've got the foundation! We've built a robust and automated system that:

Connects to an external API securely.
Processes and stores historical data for multiple entities (cities).
Runs daily, at no cost, thanks to GitHub Actions.
Is designed to scale efficiently.

In the next post, we'll put on our frontend developer hats and build the interactive dashboard that will allow any user to explore this data with dynamic graphs. Don't miss it!

References and Links of Interest:

Complete Web Service: See the live project in action here: https://datalaria.com/apps/weather/
Project GitHub Repository: Explore the source code and project structure: https://github.com/Dalaez/app_weather
OpenWeatherMap: Weather API documentation: https://openweathermap.org/api
Python Requests: Documentation for the HTTP requests library: https://requests.readthedocs.io/en/master/
GitHub Actions: Official GitHub Actions guide: https://docs.github.com/en/actions
Netlify: Official Netlify website: https://www.netlify.com/

Coder Legion - Recent posts tagged netlify

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

Introduction

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

Option 2: Netlify (Great All-Rounder)

Option 3: GitHub Pages (Simplest for Static Sites)

Common Beginner Mistakes

Final Thoughts

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

The Distinction Nobody Explains: Functional vs. Performance Fidelity

Why ISR and PPR Are Hard for Non-Vercel Platforms

Platform-by-Platform Breakdown

Vercel

Netlify

Cloudflare Workers (via OpenNext)

AWS Amplify

Railway & Render (Container/Docker Platforms)

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

Quick Comparison

So, Which One Should You Actually Use?

Frequently Asked Questions

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

Is PPR available everywhere yet?

Will the new Adapter API make all platforms equal eventually?

Is self-hosting actually cheaper?

Can I switch platforms later if I start with Vercel?

Platform Migration Difficulty

Wrapping Up

Useful Resources

Continue Learning

Back-End Web Development — VPS vs Vercel vs Netlify

Introduction

What is a VPS?

What are the benefits of a VPS?

How does it stack up against Vercel or Netlify?

Now the VPS.

References

Why Your API Calls Are Being Blocked in the Browser (and How to Fix It in 12 Lines)

What CORS Actually Is

Why APIs Block Browser Requests on Purpose

The Fix: A Serverless Proxy

Step 1 — Create the function file

Step 2 — Write the proxy (12 lines)

Step 3 — Set your environment variable

Step 4 — Call the proxy from your frontend

Why This Works

Testing Without Deploying

Extending the Pattern

What About Rate Limits?

The Full Working Dashboard

Weather Service Project (Part 1): Building the Data Collector (Python, GitHub Actions or Netlify)

The First Step: Talking to the OpenWeatherMap API

The "Database": Why CSV and Not SQL?

The Automation Robot: GitHub Actions to the Rescue

Security First: Never Upload Your API Key!

The Robot's Brain: The .github/workflows/update-weather.yml File

The Serverless Alternative: Deployment and Automation with Netlify

Deploying the Static Frontend with Netlify

Automating the Backend with Netlify Functions (and Cron Jobs)

The Scaling Problem (and the Necessary Architectural Pivot)

Conclusion (Part 1)

References and Links of Interest:

The Robot's Brain: The `.github/workflows/update-weather.yml` File