标签：#NeXT

The Redbelly Network EligibilitySDK is the compliance backbone for any dApp that needs to verify user eligibility (KYC, KYB, investor accreditation) before letting a wallet in. The official documentation covers each piece well on its own reference page, but there is no single walkthrough connecting the frontend widget to the backend verifier to the on-chain permission check to a production deployment. This guide is that walkthrough. Everything here was verified against the live documentation at https://docs.redbelly.network/ in July 2026: contract addresses, route names, config fields, issuer DIDs and every error string in the reference section. Every code example was then compiled against the published SDK package (v0.0.31) on React 19 with Vite and on Next.js 16 with the App Router, and the backend verifier was booted and exercised for real. Where the docs and reality diverge (a quickstart repo that is not publicly visible, a credential faucet still under development, three undocumented behaviours the builds surfaced), the guide says so and gives you the workaround. What you will build, in order: A mental model of the two verification mechanisms (and why conflating them costs you a day) A working backend verifier with the three routes the widget demands A plain React integration with full loading and error states A production-grade Next.js App Router setup: secure proxy, SIWE sessions, request gating, and both static and dynamic rendering approaches An end-to-end test run on Redbelly Testnet The decision logic for choosing between the three SDK flows, and the pattern for combining them A complete error reference: every documented error, its cause, and its fix A developer following this guide should have the widget running inside an existing dApp within about four hours. 1. Overview and Architecture What the EligibilitySDK actually is The Redbelly "Onboarding and Eligibility Kit" ( @redbellynetwork/eligibility-sdk ) is a set of React components and hooks for provin

Bad nextjs folder structure does not show up on day one. It shows up at month six when three developers search for the checkout form hook and find four copies. I reorganised a client dashboard after exactly that — this guide is the tree I use now on large App Router projects, why each folder exists, mistakes from my first Next.js apps, and the 10-second findability rule . Real folder tree — production-shaped layout my-app/ ├── app/ # routes only — thin pages │ ├── (marketing)/ # route group — shared layout, no URL segment │ │ ├── layout.tsx │ │ ├── page.tsx │ │ └── pricing/page.tsx │ ├── (dashboard)/ │ │ ├── layout.tsx │ │ └── orders/page.tsx │ ├── api/ # route handlers │ │ └── webhooks/stripe/route.ts │ ├── layout.tsx # root layout │ └── globals.css ├── components/ # shared UI — buttons, cards, shell │ ├── ui/ │ └── layout/ ├── features/ # business domains — colocated logic │ ├── auth/ │ │ ├── components/ │ │ ├── hooks/ │ │ └── actions.ts │ └── orders/ │ ├── components/ │ ├── api.ts │ └── types.ts ├── lib/ # server + shared utilities │ ├── db.ts │ └── env.ts ├── hooks/ # truly global client hooks ├── types/ # global TS types ├── data/ # static data, blog posts list └── public/ Routes live in app/ . Business logic lives in features/ . Generic design system pieces live in components/ui . That separation is the whole game. Why each folder exists Folder Purpose Do not put here app/ URLs, layouts, loading.tsx Fat business logic features/ Domain modules (orders, auth) Generic Button components/ui Reusable primitives Order-specific tables lib/ DB clients, env validation React components app/api Webhooks, REST edge cases Every form POST (prefer actions) Thin pages — route files under 40 lines // app/(dashboard)/orders/page.tsx — orchestration only import { OrderTable } from "@/features/orders/components/OrderTable"; import { getOrders } from "@/features/orders/api"; export default async function OrdersPage() { const orders = await getOrders(); return ( <section> <h1>Orders

React is a library, Next.js is a framework — here's what that actually means for your project, and how to choose based on SEO, scale, and team.

Sanity Embeddings semantic search in Next.js is one of those features that looks complicated from the outside but is surprisingly lean to wire up once you understand the moving parts. This post covers the current native Embeddings feature built into Sanity datasets — not the older Embeddings Index API, which Sanity is sunsetting. If you found a guide that talks about a separate embeddings-index resource you have to provision via the Management API, it is stale; skip it. What Sanity Embeddings actually is Sanity's native Embeddings feature lets you mark document types for vector indexing directly inside your dataset. Sanity handles the embedding model and the vector store; you never manage a separate service. Queries use a dedicated sanity.embeddings.query GROQ function that takes a natural-language string and returns documents ranked by semantic similarity. The feature is available on Growth and Enterprise plans as of mid-2026. The workflow has three parts: Configure which document types get indexed (dataset setting or the Embeddings pane in Sanity Studio). Run a semantic query from your Next.js route handler using the Sanity client. Render the results in a search UI component. Setting up the embeddings index in your dataset Go to Manage → your project → Embeddings (or open the Embeddings pane inside Sanity Studio if your plan surfaces it there). Create an index, give it a name (e.g. site_search ), and select which document types and fields to embed. For a blog you would typically pick post with fields title , excerpt , and body (plain text extracted from Portable Text). Sanity backfills existing documents automatically. New and updated documents are re-embedded on publish via an internal webhook — you do not configure that yourself. There is no code required for the indexing step. The index name you choose here ( site_search ) is what you will pass in the GROQ query. Querying embeddings from a Next.js route handler Create a route handler that accepts a search term,

Everything worked. I'd wired up useOptimistic on a task list, the checkbox flipped the instant you...

I wanted a media library that knew the difference between what should exist and what does. Most automation I tried picked one side. Some tools search well and never track what you already have. Others move files and assume the move worked. I wanted the gap between those two things to be the thing the software acted on. So I built Mediary Scout . You name a movie or a show. An LLM agent searches your indexers, transfers the best match into your own cloud drive, then reads the drive back to confirm what landed and what is still missing. It runs self-hosted. You bring your own drive, your own model, your own metadata key. There are desktop builds for Mac and Windows if you just want to double-click and run it, and a read-only demo if you want to watch one acquisition play out first. The drives it speaks today happen to be Chinese cloud storage (115, Quark, GuangYaPan). That detail does not matter for the rest of this post. The part that took real work was different: handing an LLM tools that move and delete files, and stopping it from doing something dumb with them. Three bugs taught me most of what I now believe about that. The shape of the thing The web app does almost nothing interesting. It writes a row to a Postgres queue and returns. A long-running worker picks up the row and starts a sandboxed agent. The agent gets a small set of tools: search resources, transfer a candidate, list a directory, move files into a season folder, mark episodes as obtained. Every tool runs through a deterministic workflow that owns the actual side effect. The agent proposes. The workflow decides whether the proposal is allowed, performs it, and reads the world back. That split is the whole design. The model is the part I cannot fully predict, so it gets the smallest possible blast radius. The deterministic code around it holds every irreversible action and every check. When I violated that split, things broke. They broke in the order below. Bug 1: the agent searched sixteen times and

Four years of optimizing React and Next.js projects taught me one thing: unoptimized images are everywhere, and nobody wants to fix them. Every project has the same pattern. Heavy PNG and JPG files are sitting inside /public , there is no consistent image pipeline, and some of those files have no business being that large in a production codebase. This is especially common in small and mid-sized projects. There is no CDN transformation layer or dedicated asset pipeline. Images get added while the product is moving quickly, and the cleanup becomes a task for “later.” Later, of course, never comes. Then, at 1am, while refactoring an extremely vibe-coded Next.js project, I found myself doing the cleanup manually again. Find an image. Upload it to an online compressor. Hit the free limit. Open another tool. Convert a few more. Download everything. Replace the original files. Hunt through the codebase for every import and src path. Hope I did not miss one. And I finally thought: I am a developer. Why am I doing this by hand? So I built pixcrush . npx pixcrush . One command to convert the images, compress them, and update their matching code references automatically. “But doesn’t Next.js already optimize images?” Yes, and if your application uses next/image consistently, you should absolutely take advantage of it. The Next.js <Image> component can resize images for different devices, lazy-load them, and serve modern formats such as WebP. Files inside /public can be referenced from the root URL, while statically imported images also give Next.js access to their intrinsic dimensions. The official Next.js image documentation explains these runtime optimizations in detail. But that solves a different layer of the problem. I wanted to clean up the source assets themselves: Replace heavy PNG and JPG files with smaller WebP files when conversion is worthwhile. Update existing imports and string-based image paths across the repository. Identify images that are no longer reference

We are two friends building Pageonaut , a collection of 126 free browser tools (converters, calculators, PDF and image utilities, dev helpers). Early on we committed to one constraint: everything runs client-side . No file uploads, no accounts, no server-side processing. That one decision shaped the whole architecture, and it broke things in ways I did not expect. Here are the lessons, including the one where our server filled up with 419 GB of cache and took the site down twice. Why client-side only Every time I needed a quick converter, the top search results wanted me to upload my file to their server, create an account, or pay to remove a watermark. For work that a browser can trivially do locally. So the rule became: drop a file into one of our converters and it never leaves your device. You can watch the network tab while using it. This is great for privacy and trust, and it has a nice side effect: our server does almost nothing per user, so hosting stays cheap even if a tool gets popular. The cost: some tools are genuinely harder to build. PDF manipulation in the browser (we use client-side libraries instead of a server queue), image processing on the main thread without freezing the UI, and no "just call an API" escape hatch. When a tool truly needs the network (say, fetching a URL you give it), the page says so explicitly. Lesson 1: Unbounded URL params + ISR = a full disk This is the expensive one. We built shareable challenge pages: beat my score, try this color, that kind of thing. The URLs look like /tools/<slug>/challenge/<value> , where <value> is user-generated. With Next.js ISR, every unique URL that renders gets persisted to the filesystem cache. You can see where this is going. The value space is infinite. Bots found the pattern and started enumerating it. .next/server/app grew to 419 GB . The disk filled up, the site went down, and because we did not understand the root cause immediately, it happened a second time a few days later. The fix was tw

Most API authentication I've seen in production follows the same pattern: a single apiKey check at the top of each route handler, maybe a rate limiter slapped on as middleware, and a quota check that lives in the database layer. It works — until you have 673 routes across 3 access tiers, and you realize you can't answer the question "which routes require a paid subscription?" without grepping every file. I ran into this exact problem building the APE-QIL QUANTUM SUPREME OCTOPUS — a Bio-inspired Autonomous Intelligence Organism that operates as an AI routing platform with 14+ provider integrations. The codebase has 673 API routes divided into three access tiers: public (79 routes), free API key (337 routes), and paid subscription (255 routes). Manually maintaining auth on each route was untenable. So I built a composable request pipeline that makes the auth structure declarative and CI-enforced. This post walks through the architecture: the 3-tier sovereign auth model, the composable withRequestPipeline function, and the CI guard that fails the build if any protected route is missing its wrapper. The 3-Tier Sovereign Auth Model The access model is deliberately simple — three tiers, each with a clear boundary: // TIER 0 — Public, no auth (79 routes) // Health checks, pricing, blog, lead magnet, metrics // Example: /api/health, /api/pricing, /api/blog/* // TIER 1 — Free API key required (337 routes) // Any valid API key in the database grants access // Enforced via: withSovereignAuth('free') // Example: /api/v1/chat/completions (free tier limits) // TIER 2 — Paid subscription required (255 routes) // Requires Pro ($79/mo) or Business ($249/mo) tier // Enforced via: withSovereignAuth('professional') // Example: /api/v1/chat/completions (premium models, higher limits) The key design decision: the tier is declared at the route level, not inferred from the user's subscription at runtime. This means the route registry itself is the source of truth for "what requires what."

Website performance is no longer just a nice-to-have feature—it's a critical factor for user experience, SEO, and business success. Even a one-second delay in page load time can reduce conversions and increase bounce rates. Whether you're building a portfolio, SaaS application, eCommerce platform, or business website, these optimization techniques can make a significant difference. Optimize Images Images are often the largest assets on a webpage. Use modern formats like AVIF or WebP, compress images, and serve responsive image sizes to reduce bandwidth usage. Self-Host Fonts Third-party font requests add latency. Self-hosting fonts, preloading critical font files, and serving only the required character subsets can dramatically improve loading performance. Remove Unused CSS & JavaScript Shipping unnecessary code increases download size and execution time. Tree shaking, code splitting, and removing unused styles help keep your bundle lean. Enable Caching Configure long-term browser caching for static assets and use hashed filenames for cache busting. This allows returning visitors to load your website much faster. Use Lazy Loading Images, videos, and iframes that aren't immediately visible should load only when needed. Native lazy loading is supported by modern browsers and is easy to implement. Optimize Core Web Vitals Google's Core Web Vitals measure how users experience your website. Focus on: Largest Contentful Paint (LCP) Interaction to Next Paint (INP) Cumulative Layout Shift (CLS) Improving these metrics benefits both SEO and user satisfaction. Minify Assets Minify HTML, CSS, and JavaScript files before deployment. Smaller files transfer faster and improve overall performance. Use a CDN Serving assets from edge locations around the world reduces latency and improves loading times for global visitors. Prioritize Accessibility Accessible websites provide a better experience for everyone and often align with SEO best practices. Use semantic HTML, descriptive labe

Week 16 shipped the AI background remover: Rust-native, ort + ISNet + libvips, no Python. That was the feature. Week 17 was not about writing more of it. It was about the boring, high-leverage part that most side projects skip: turning one working feature into pages that can actually rank, and wiring those pages together so search engines can find them. No new engine code this week. Just leverage on what already existed. Here is what that actually looked like. The problem: a hub with nothing pointing at it The background remover lives at /remove-background . That is the hub. The plan was classic hub-and-spoke: one general tool page, then use-case spokes that each target a specific intent (removing a signature background, prepping an Amazon product photo, and so on). I built two spokes this week. But halfway through, I looked at how internal links actually worked on the site and found the real problem: nothing linked from the hub to the spokes. The spokes linked back to the hub in their body text, but the hub had no idea they existed. Neither did the ~180 converter pages. Tool links on the site were hardcoded in a frontend constant, roughly: export const IMAGE_TOOLS = [ { label : " Compress JPG " , href : " /compress/jpg " , tool : " compress " }, { label : " Resize Image " , href : " /resize-image " , tool : " resize " }, { label : " Crop Image " , href : " /crop-image " , tool : " crop " }, { label : " Images to PDF " , href : " /images-to-pdf " , tool : " convert " }, ] as const ; That list covered the converter tools. It did not include the background remover or its spokes at all. So the new pages were orphans: reachable only through the sitemap, with no internal links carrying any signal to them. For a domain that is still young and still earning Google's trust, orphan pages get discovered slowly and rank even slower. The fix: one constant as the source of truth Instead of hardcoding links in three different places, I made a single constant describe the whole cl

If you've ever received a .pages or .numbers file on a Windows PC, you know the pain — you can't open it. No preview, no converter built in, and Apple's iCloud web tools are slow and clunky. So I built iworkviewer.com — a free, browser-based iWork file viewer and converter. No signup, no upload to any server. Everything happens in your browser. What it does Open .pages files → view them instantly, export to PDF or .docx Open .numbers files → view spreadsheets, export to .xlsx or PDF Open .keynote files → view presentations, export to PDF or .pptx Batch convert multiple iWork files at once The tech Built with Next.js, Cloudflare Pages, and pure client-side JavaScript. All file processing happens in the browser — your files never leave your computer. Zero server costs, zero privacy concerns. Why I built it I kept seeing Reddit threads and Quora questions: "How do I open a Pages file on Windows?" The answers were always the same — use iCloud.com (slow), download some sketchy converter (risky), or ask the sender to export as PDF first (annoying). I figured: if the browser can read a file, it can convert it. And it turns out, it can. Try it 👉 iworkviewer.com Open a .pages, .numbers, or .keynote file right in your browser. Free, forever, no account needed.

My dashboard had a useMemo doing arithmetic it had no business doing. It was a Pokémon TCG Pocket collection tracker, but that part doesn't matter. What matters is that the home page needed to show three things: overall completion, completion per set, and which set you were closest to finishing. The way I'd built it, the browser was fetching every card and every owned record, then grinding through the math on each render to figure all of that out. It worked. It also got slower and harder to read every time the data grew or I added a metric. So I moved the aggregation out of React and into Postgres, and the surprising result was that my frontend got boring . Fewer hooks, less state, almost nothing left to break. That's the whole argument of this post: aggregation belongs in the database, and when you put it there, the React code that's left over is the kind of boring you actually want in the layer your users touch. What "fetching everything into React" actually looks like Here's the shape of the original dashboard. Load all the cards, load the user's owned rows, then derive everything on the client. const [ cards , setCards ] = useState < Card [] > ([]); const [ owned , setOwned ] = useState < OwnedCard [] > ([]); useEffect (() => { ( async () => { const { data : allCards } = await supabase . from ( " cards " ). select ( " * " ); const { data : ownedRows } = await supabase . from ( " user_cards " ) . select ( " card_id " ); setCards ( allCards ?? []); setOwned ( ownedRows ?? []); })(); }, []); const ownedIds = useMemo (() => new Set ( owned . map (( o ) => o . card_id )), [ owned ]); const perSet = useMemo (() => { const groups : Record < string , { total : number ; have : number } > = {}; for ( const card of cards ) { const g = ( groups [ card . set_id ] ??= { total : 0 , have : 0 }); g . total += 1 ; if ( ownedIds . has ( card . id )) g . have += 1 ; } return groups ; }, [ cards , ownedIds ]); const overall = useMemo (() => { const total = cards . length ; const ha

i did something dumb last month. on purpose. i sat down, opened a next.js app, and tried to make hydration fail in every way i could think of. not because a bug forced me to. not because i was debugging something. just because i wanted to see it. understand it from the inside. and honestly? best few hours i've spent learning anything in a while. why i even did this you know how you use something for months and you think you get it, but you don't really get it? hydration was that for me. i knew the surface-level thing: server renders HTML, client takes over, they gotta match. cool. got it. moving on. except i didn't get it. i just got the vibe of it. every time i saw hydration mismatch, i'd ask claude, fix the immediate thing, feel vaguely annoyed, and move on. i never stopped to ask why that specific thing broke it. i was treating symptoms, not understanding the actual disease. so i decided to break it deliberately. if i caused the errors myself, i'd actually have to understand what i was doing. the setup basic next.js app. app router. a few pages. nothing fancy. i wasn't trying to build anything. i was trying to destroy something, carefully, so i could see what fell apart and why. break #1: the obvious one - new Date() on render this is the classic. everyone's seen it. export default function Page () { return < div > { new Date (). toLocaleString () } </ div > } server renders this at, say, 14:00:00. by the time react runs on the client and tries to reconcile, it's 14:00:01. the strings don't match. react screams. thing is, i knew this would happen. what i didn't think about was why react cares. here's the thing: react isn't doing a full diff on the entire DOM after hydration. it's trusting that the server HTML is a valid starting point and it's just attaching event listeners and state to it. but if the content doesn't match, it doesn't know what to trust. it can't partially hydrate "mostly correct" HTML. it either matches or it doesn't. so it throws the warning, a

The three-layer model works. Part 1 of this series is the invoice incident that proved it. Part 2 is...

This blog post is created for the purposes of entering the Hack the Zero Stack with Vercel v0 and AWS Databases hackathon. #H0Hackathon Building Innward: A B2B Hospitality Operating System with Vercel and Amazon Aurora The hospitality industry is notorious for relying on "legacy" software—clunky, slow, and disconnected. For the Hack the Zero Stack hackathon, I set out to build Innward , a modern, AI-ready Property Management System (PMS) that proves you can build enterprise-grade B2B tools in record time using Vercel v0 and AWS Databases. The Vision: Moving Beyond the Spreadsheet Hotel managers don't just need a place to store "Room 101: Occupied." They need to solve the "Hidden Math" of revenue management. This means: Relational Complexity: Linking dates, room groups, and individual stays. Dynamic Pricing: Deriving rates based on occupancy and logic-based rules. Market Intelligence: Real-time benchmarking against competitors. The "Zero Stack": Vercel + Amazon Aurora To handle this complexity, I chose Amazon Aurora PostgreSQL (Serverless v2) . Why Aurora for B2B? In a B2B SaaS environment, data isolation and relational integrity are non-negotiable. Aurora provided the robust relational power needed to join complex pricing tables while scaling automatically as more hotels (tenants) join the platform. The Zero-Secret Architecture One of the most rewarding parts of this build was implementing the AWS RDS Signer . Following the "Zero Stack" philosophy, I moved away from static database passwords. Innward uses IAM-based authentication to communicate between Vercel and AWS. By utilizing the @aws-sdk/rds-signer , the application generates short-lived tokens on the fly. This means even if an environment variable were leaked, the database remains locked tight. // lib/db.ts snippet const signer = new Signer ({ credentials : awsCredentialsProvider ({ roleArn : process . env . AWS_ROLE_ARN ! , clientConfig : { region : process . env . AWS_REGION }, }), region : process . env .

Every Sanity marketing site ends up with a page builder. An array of sections, an insert menu, a render loop that maps block._type to a component. You've built it. I've built it. We've all built the same thing. And every one of them ships with the same bug. You add a new section. You wire it into the schema. You add a renderer. You add a component. You add the type. And then — because there are five places to touch and you're a human — you forget one. The section renders blank in production. Or it never shows up in the insert menu. Or it fetches no fields because you missed the GROQ projection, so it renders as nothing at all. No error. No red. Just a hole on the page where a section should be. The annoying part isn't the bug. It's that you'll hit it again on the next project, in exactly the same way, because you rewrote the whole thing from scratch — again. The section tax Here's what "add a section" actually costs in a typical Sanity + Next.js page builder: Schema — a new *Section object type, registered in your schema index. GROQ — a new conditional in the page-builder projection so the block's fields actually come down. Component — the React component that renders it. Renderer map — an entry mapping _type → component. Types — the block variant in whatever union your frontend renders. Miss #2 and the block arrives empty. Miss #4 and it silently skips. Miss #5 and TypeScript shrugs because your union is hand-maintained and now lies. Three different failure modes, all of them quiet, all of them "works on my machine until it doesn't." Now look at those five places and ask: which of them is actually unique to your site? The component is. It's welded to your design system — your spacing, your tokens, your brand. Nobody can reuse it and nobody should. The other four are plumbing . "Look up _type in a map, call the renderer, keep the map in sync with the schema and the query." That code is byte-for-byte the same idea on every project you've ever built. So why is it livi

Today, we’re excited to launch UIAble v1.0, an open-source component library built for developers, by developers. We explored a lot of UI libraries built on Shadcn. Most of them feel nearly identical — same structure, same aesthetic, same tradeoffs. That’s what pushed us to build something different. Not another library that looks like Shadcn with a coat of paint, but a design system with its own identity and a clearer sense of what it’s actually for. Why UIAble exists After enough frontend projects, one thing becomes obvious: the same UI patterns get rebuilt again and again. Inputs. Dialogs. Tables. Alerts. Dropdowns. OTP fields. Form validation states. Not because they’re hard to build, but because most existing libraries never quite fit real project requirements. Some are too opinionated. Some pile on unnecessary abstraction. Some become rigid after initial setup. And some make simple UI unnecessarily complicated. That friction is what led to UIAble. Not to launch another oversized library, just to build a cleaner, more practical foundation for modern frontend development. What UIAble actually is UIAble is a free, open-source UI component library built with Tailwind CSS , Shadcn-style architecture , and Base UI principles . The idea is straightforward: reusable components should stay flexible, readable, and easy to maintain. Instead of pulling projects into a rigid ecosystem, UIAble gives you components you can copy directly into your codebase, edit freely, and scale without fighting the library. No lock-in. No unnecessary abstraction. No dependency trap. What makes it different in practice A few things actually matter here. You get the code. UIAble doesn’t hide logic behind layers of packaging. You see the component. You edit it. You ship it. That alone changes how teams work with UI. It’s built for real product UI, not showcase pages. A lot of UI kits look great in demos and fall apart in production. UIAble focuses on the unglamorous stuff, forms that don’t bre

Living in the UAE means constantly Googling numbers: what is the visa fee now, how much zakat do I owe, what is today's fuel price, how is my gratuity calculated. The answers online are usually outdated. So I built Adad , a free set of 15 calculators that pull from official UAE government sources and refresh every 24 hours. No sign-up, works in 8 languages. A few that people use most: Visa fees: real GDRFA and ICA rates Zakat: gold, silver, savings DEWA bills: estimate before the bill lands Gratuity: UAE labour-law end-of-service It is at adad.ae if it is useful to you. Happy to answer how the data pipeline stays current.

Vercel m'a longtemps convenu. Tu pousses ton code, trente secondes plus tard c'est en ligne avec un certificat valide, un CDN et des previews par branche. Pour démarrer un projet, je ne connais rien de plus confortable. Le problème arrive après, quand le projet vit. La facture grimpe avec le trafic et les fonctions serverless, certaines fonctionnalités propriétaires deviennent compliquées à reproduire ailleurs, et tu finis par ne plus vraiment savoir où ni comment ton app tourne. C'est un excellent point de départ, et un piège dès qu'on veut maîtriser son coût et son infra. Pour ce portfolio comme pour plusieurs projets clients, j'ai pris le chemin inverse. Un VPS à quelques euros par mois, une image Docker, un reverse proxy, un pipeline maison. L'idée n'est pas de revenir à l'âge de pierre du déploiement par FTP : je garde le « git push et c'est en ligne », mais sur une machine que je contrôle de bout en bout. Voici comment c'est câblé, et les deux ou trois endroits où je me suis fait avoir. L'image Docker : tout repose sur le mode standalone La pièce qui change tout, c'est output: "standalone" dans next.config.ts . Au build, Next trace exactement les fichiers nécessaires au runtime et les recopie dans .next/standalone/ . On passe d'une image d'environ 1 Go à environ 200 Mo. Sans ça, tu traînes tout node_modules dans ton conteneur de prod pour rien. Le Dockerfile est multi-stage : une étape pour installer les dépendances, une pour builder, une dernière qui ne garde que le strict nécessaire. # deps : installe les dépendances (cache Docker optimal) FROM node:22-alpine AS deps WORKDIR /app COPY package.json yarn.lock .yarnrc.yml ./ RUN corepack enable && yarn install --immutable # builder : build l'app FROM node:22-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN corepack enable && yarn build # runner : image finale, non-root FROM node:22-alpine AS runner WORKDIR /app ENV NODE_ENV=production RUN addgroup -g 1001 nodejs && a