DEV Community: Devarshi Shimpi

How the Bitcoin Network Actually Works

Devarshi Shimpi — Sun, 26 Jul 2026 00:14:33 +0000

Bitcoin gets called a lot of things: digital gold, internet money, a scam, a revolution. This guide skips all of that. It is not about what Bitcoin is for. It is about what Bitcoin is: the parts, how they fit, and why they work.

We are going to build the idea up in layers, because that is genuinely how Bitcoin is put together. Each layer sits on top of the one below it. If you skip a layer, the ones above look like magic. If you take them in order, the magic turns into something more satisfying: plain engineering.

A quick note on numbers. The rules in this guide (how often blocks appear, the coin limit, how a block is structured) are fixed by the software and do not change. The live figures (how much computing power is on the network, how busy it is, the price) change all the time. Where I mention one of those, treat it as "roughly true in mid-2026" and check a live site for today's value.

What we are actually looking at

Here is the one-sentence version of the whole thing:

Bitcoin is a way for a huge group of strangers, who do not trust each other and have no boss, to agree on a single shared list of who owns what.

That is harder than it sounds. Normally, when a group needs to agree on something, someone is in charge. A bank keeps the official record of your balance. A referee makes the call. Bitcoin has no one in charge, and some of the people taking part may be actively trying to cheat. Somehow it still ends up with one agreed answer.

By the end of this guide you should be able to explain, in your own words, why a coin cannot be spent twice, why sending Bitcoin costs a fee, why the mining difficulty keeps adjusting up and down, why "running a node" and "mining" are two completely different jobs, and what actually happens in the roughly ten minutes between tapping send and the payment becoming permanent.

The one problem Bitcoin was built to solve

Everything starts here, so it is worth slowing down.

The problem is called double spending, and it only exists for digital money.

Think about a physical $20 bill. When you hand it to a shop, you no longer have it. The object moved from your hand to theirs. You physically cannot be in two shops spending the same bill at the same time.

Now think about anything digital: a photo, a song, a file. Copying it is free and perfect. You can send the exact same photo to a thousand people at once, and each copy is flawless. That is great for photos. It is a disaster for money. If a "coin" were just a file, you could send the same coin to a thousand different people, and each one would see a perfectly real coin. Only later would everyone realise they were all paid with the same money.

The usual fix is to put someone in charge. A bank keeps one official list. When you pay, the bank subtracts from your row and adds to someone else's row. Because there is only one list, controlled by one company, the same dollar cannot be in two places. This works, and most of the world runs on it. But it comes with a cost. You have to trust that company. It can freeze you, reverse payments, get hacked, go under, or simply charge you for the service.

So the question that led to Bitcoin was very specific:

Can you keep one official list of who owns what, without anyone being in charge of the list?

Two pieces of math hold up everything else

Almost every surprising thing about Bitcoin comes from one of two tools. Neither was invented for Bitcoin. Both are decades old and used all over the internet.

Tool 1: the fingerprint machine (a hash)

A hash function is like a machine that takes anything you feed it (a word, a file, an entire book) and spits out a short jumble of characters. Bitcoin uses one called SHA-256, whose output is always 64 characters long. Feed in a single letter or the complete works of Shakespeare, and you still get exactly 64 characters back. People often call this output a fingerprint, and that is the word I will use.

Three things make it special, and the whole security of Bitcoin leans on them:

Same input, same fingerprint, every time. Anyone, anywhere, feeding in the same thing gets the same result. No coordination needed.
Change the input a tiny bit, and the fingerprint changes completely. There is no "close." Change one letter and about half the output flips, with no pattern connecting the two.
You cannot run it backwards. Given a fingerprint, there is no way to figure out what was fed in, other than guessing. And there are so many possible fingerprints that guessing is hopeless. (For scale: the number of possible outputs is far larger than the number of atoms on Earth.)

Point 2 is the one people underestimate, so here it is made concrete. These two inputs differ by a single letter:

"Bitcoin"  ->  b4056df6691f8dc72e56302ddad345d65fead3ead9299609a826e2344eb63aa4
"bitcoin"  ->  6b88c087247aa2f07ee1c5956b8e1a9f4c7f892a70e324f1bb3d161e05ca107b

One lowercase letter, and 62 of the 64 characters came out different. Underneath them, about half of the 256 bits flipped. There is no pattern connecting the two results.

Try it live: type any word and watch the diff highlight, character by character

This matters a lot later. Because there is no "getting warmer," you cannot be clever and steer a fingerprint toward a shape you want. Your only option is to try, check, and try again. Remember that.

A good way to build intuition is to feel it yourself.

Try it live: a SHA-256 playground that rehashes on every keystroke. Type something, delete one character, and watch the whole 64-character output rearrange.

One more detail for the curious: Bitcoin usually runs this machine twice in a row, taking the fingerprint of the fingerprint. You do not need to remember why. Just know that when you hear "the block's ID" or "the transaction ID," that is one of these fingerprints.

Tool 2: a lock only you can close, that anyone can check

The second tool answers a different question: how do you prove you are allowed to spend a coin, without giving away a secret that would let anyone else spend it too?

The answer is a matched pair of keys:

A private key, which is basically a giant secret random number that only you know.
A public key, which is calculated from the private key and which you can share freely.

Like the fingerprint machine, this only runs one way. It is easy to make the public key from the private key, and effectively impossible to go backwards.

With this pair you can do two things:

Sign. Using your private key, you can stamp a specific message (a payment) with a unique signature. The signature only works for that key and that exact message.
Verify. Anyone with your public key can check that the signature is real, which proves you made it, without ever seeing your private key.

A helpful picture: think of a special wax seal that only your ring can press, but that anyone in the world can recognise on sight. You never hand over the ring. You just stamp things, and everyone can confirm the stamp is yours.

This is the entire idea of owning Bitcoin. A coin is not sitting "inside" a wallet like a file in a folder. To own Bitcoin simply means you know a private key that can produce a valid signature to move that coin. Lose the key and the coins are stuck forever. There is no support line and no reset button. That is what people mean by the phrase "not your keys, not your coins."

From a secret number to an address

You have probably seen a Bitcoin address, one of those long strings starting with bc1. Here is where it comes from, and it is just the two tools from the previous section (the fingerprint machine and the key pair) chained together.

The path runs in one direction only:

private key -> public key -> address

Each arrow is easy to walk forwards and practically impossible to walk backwards. You make the public key from the private key using the key math. Then you make the address by taking the fingerprint of the public key.

Because of that one-way street, two everyday facts fall out:

Sharing your address is safe. It is downstream of everything secret, so it gives nothing away. People can send you money, and that is all.
Sharing your private key is a catastrophe. It is the thing at the very start of the chain. Anyone who has it can sign, which means they can spend everything.

You may notice addresses start with different prefixes. A quick key:

Starts with	Technical name	Plain meaning
`1...`	P2PKH (legacy)	the original address style
`3...`	P2SH	often used for shared or multi-key setups
`bc1q...`	native SegWit v0 (Bech32)	cheaper, more efficient addresses, from the 2017 SegWit upgrade
`bc1p...`	Taproot / SegWit v1 (Bech32m)	the newest style, from the 2021 Taproot upgrade

They all do the same basic job: they are a safe-to-share destination for money. As a quick rule of thumb, Taproot addresses commonly start with bc1p, and the older native SegWit addresses start with bc1q.

Blocks, and why they form a chain

Now we can build the record itself.

A block is simply a batch of transactions bundled together, plus a small label on top called the header. Think of a block as one page in a shared notebook. The page has a body (the list of payments) and a heading (the summary info). New pages are added roughly every ten minutes, and each page can hold a few thousand payments.

The header is small but it is where the clever part lives. The whole thing fits in 80 bytes:

Field	Size	What it does
Version	4 bytes	which rules this block follows
Previous block's fingerprint	32 bytes	the link that chains blocks together
Merkle root	32 bytes	one fingerprint summing up every transaction
Timestamp	4 bytes	roughly when the block was made
Target ("bits")	4 bytes	how hard the puzzle is right now
Nonce	4 bytes	the number miners keep changing to win

Notice that two fields eat 64 of the 80 bytes, and both of them are fingerprints. That tells you what a header is really for.

Try it live: tap through the header drawn to scale, where each field's width matches its byte count.

The single most important field is the previous block's fingerprint. Every block's header contains the fingerprint of the block right before it. That one detail is what turns a pile of separate pages into a connected chain.

Here is why that chain is so powerful. Imagine a cheater wants to secretly change a payment in an old block. The moment they change anything in that old block, its fingerprint changes (that is the fingerprint machine from earlier). But the next block was carrying the old fingerprint. So now the next block does not match, and its own fingerprint would need to change too, which breaks the block after that, and so on all the way to the present.

In other words, you cannot quietly edit page 400 of the notebook. Editing it visibly wrecks every page after it. To make the change stick, the cheater would have to redo every single page from 400 to now, faster than the rest of the world is adding new pages. The section on proof of work explains why that is effectively impossible.

Merkle trees: summing up thousands of payments with one fingerprint

You may have spotted a field in the header called the Merkle root. It sounds fancy. The idea is simple and genuinely elegant.

A block might hold thousands of transactions. The header does not want to store all of them, but it does want a way to lock them in so none can be swapped out later. The trick is to squash all of them down into a single fingerprint, built like a knockout tournament.

Pair up the transactions and take a fingerprint of each pair. Then pair up those fingerprints and hash them. Keep going until only one fingerprint is left standing. That final winner is the Merkle root, and it goes in the header.

Two nice things come out of this:

Nothing can be swapped. Change any single payment and its fingerprint changes, which changes its pair, which changes the root, which changes the whole block. The root locks everything in.
You can prove one payment is in a block without downloading the whole block. This is how a phone wallet can confirm your payment landed without storing the entire history of Bitcoin. It only needs a short trail of fingerprints up the tree, not the thousands of other payments.

Coins are not a balance, they are more like cash

This is the part that trips up almost everyone, because it works differently from a bank.

Your bank account has a single number: your balance. When you spend, the number goes down. Bitcoin does not work that way. Bitcoin is more like a wallet full of actual bills and coins of odd sizes.

In Bitcoin, when you receive money, you receive it as a distinct chunk, like being handed a specific bill. The proper name for one of these unspent chunks is an unspent transaction output, usually shortened to UTXO. You do not need the jargon. Just picture bills of random sizes sitting in your wallet.

Now, here is the cash-like rule: you cannot spend part of a bill. If you have a 0.4 coin chunk and a 0.25 coin chunk, and you want to pay someone 0.6, you hand over both chunks, the seller keeps 0.6, and the leftover comes back to you as change, as a brand new chunk. Written out, that payment looks like this:

coins going in                0.65 BTC     a 0.4 coin plus a 0.25 coin
to the seller                 0.6 BTC      the payment
back to you, as a new coin    0.049 BTC    your change
left for the miner            0.001 BTC    the fee

Try it live: pick which coins to spend and drag the payment amount to watch the change and the fee resolve.

The tiny bit that does not come back as change is the fee, which the miner who includes your payment gets to keep. There is more on fees in the section on the waiting room below.

Two everyday consequences of this design:

Your "balance" is not stored anywhere. Your wallet app just scans the record, finds every chunk that belongs to your keys, and adds them up to show you a number. Nobody wrote that number down.
Privacy is fiddly. Because change comes back as a new chunk, following the trail of chunks is how blockchain analysts try to trace activity.

Two different jobs: nodes and miners

People mix these up constantly. They are separate roles, and most participants only do one of them.

Nodes are the referees. A node is a computer running the Bitcoin software that keeps a full copy of the record and checks every single rule. Is this signature valid? Does this person actually own the coins they are trying to spend? Is this block properly formed? If anything breaks a rule, the node rejects it and refuses to pass it on. There are tens of thousands of these referees around the world, and crucially, anyone can run one on ordinary hardware. This is the real backbone of Bitcoin. The rules are enforced by thousands of independent copies, not by any authority.

Miners are the record keepers who compete for the right to add the next page. Their job is to bundle waiting transactions into a new block and win the right to add it. This takes serious specialised equipment and a lot of electricity. The next section is all about what they are actually doing.

The key thing to take away: miners propose, nodes decide. A miner can build any block it likes, but if that block breaks the rules, every honest node simply throws it away and the miner wasted its effort for nothing. Power in Bitcoin is split on purpose.

Proof of work: the guessing game you cannot cheat

This is the heart of Bitcoin, and thanks to the two tools from earlier it is now easy to explain.

To add the next block, a miner has to win a guessing game. Remember the header has a field called the nonce, which is just a number the miner is free to change. The game is this: find a nonce so that when you take the fingerprint of the whole header, the result is small enough.

To be precise: a fingerprint is really just a very large number written in hex. The header also carries a target value (packed into a small field called nBits). A block only counts as valid if its fingerprint, read as a number, comes out below that target. The lower the target, the fewer fingerprints qualify, and the harder the puzzle. The easy way to picture "below the target" is "the fingerprint has to start with a certain number of zeros," and that is the mental model I will use, but keep in mind the real rule is the numeric comparison against the target.

That is it. Because of the fingerprint machine's "no getting warmer" rule from earlier, there is no smart way to find such a nonce. You cannot calculate it. You cannot nudge the number in the right direction. You can only try a nonce, take the fingerprint, check if it has enough leading zeros, and if not, add one and try again. Over and over, billions of times per second.

You can feel exactly how this works by doing it yourself. Choose how many leading zeros you want, hit start, and your browser runs the same dumb loop a real miner does, just far slower. On my machine, asking for 4 leading zeros took 99,664 guesses and about 1.7 seconds. Ask for 5 and the work multiplies by roughly sixteen.

Try it live: mine a block by hand, with real SHA-256

Now, why is this pointless-looking effort actually useful? Because of a beautiful lopsidedness:

Very hard to do, instant to check. Finding a winning nonce takes the entire network huge effort. But checking someone else's winning block takes any referee a split second: take the fingerprint once, count the zeros, done. Making the proof is expensive. Verifying the proof is free.
Lying costs real money. A winning block represents real electricity that got burned. To rewrite an old block, a cheater would have to burn all that electricity again, plus redo every block since, plus keep outrunning the entire rest of the world adding new blocks in real time, forever. It is not that cheating is banned. It is that cheating is wildly more expensive than playing fair.

That last point is the whole security model in one line: behaving honestly pays better than attacking.

Why almost nobody mines alone

Winning a block is a lottery. If you mine by yourself, you might go months or years without ever winning, then win once, then nothing again. That wild unpredictability is unbearable for most operators trying to pay an electricity bill.

So miners team up into pools. A pool has thousands of miners all working on the same block and splitting any reward in proportion to how much work each one did. This turns a wild lottery into a steady, paycheck-like income. The downside is that it concentrates a lot of decision-making into a handful of large pools, which is one of the genuine worries about Bitcoin today.

Keeping blocks ten minutes apart, forever

Bitcoin aims for a new block roughly every ten minutes. But the amount of computing power aimed at the network is always changing. More miners join, better machines arrive, prices swing and some switch off. So how does the gap stay near ten minutes?

The network retunes the difficulty automatically. Every 2,016 blocks (which at ten minutes each works out to about two weeks), every node does the same simple check: did the last stretch of blocks arrive faster or slower than the ten-minute target? The difficulty then adjusts up or down accordingly. If the last period was mined too fast, the puzzle gets harder (the target drops, so more leading zeros are needed). If it was too slow, the puzzle gets easier. It can and regularly does move in both directions.

A good mental image is a treadmill that speeds up as more runners jump on, so that a runner still crosses the line about every ten minutes no matter how many are racing. This is why you cannot make Bitcoin produce coins faster by throwing more machines at it. Add more power and the puzzle simply gets harder to match.

Every node calculates this adjustment independently and arrives at the same answer, because they all follow the same rule on the same shared record. No committee, no announcement. Just math everyone runs.

New coins, the halving, and the 21 million limit

So where do new coins come from, and who gets them?

Whoever wins a block gets to include one special payment at the top that creates brand new coins out of nothing and pays them to the winner. This is the reward, and it is the incentive that makes people spend money on mining in the first place. The winner also collects all the fees from the transactions in that block.

Here is the famous twist. That reward cuts in half every four years (more precisely, every 210,000 blocks). It started at 50 coins per block in 2009. It dropped to 25, then 12.5, then 6.25, and in 2024 to 3.125. This is called the halving.

Halving	Reward per block	Coins in existence
2009 (start)	50	0
2012	25	~10.50M
2016	12.5	~15.75M
2020	6.25	~18.38M
2024	3.125	~19.69M
2028	1.5625	~20.34M

Each halving releases half of whatever is still left, so the total creeps toward 21 million without ever quite arriving. New coins trickle out more and more slowly until, sometime around the year 2140, the reward rounds down to zero and no new coins are ever made again.

Try it live: the supply curve, with tappable halving markers

This fixed limit is a large part of why supporters compare Bitcoin to gold. There is a hard cap, and no one can vote to print more. As of mid-2026, roughly 20.06 million of the 21 million already exist. (That figure keeps ticking up slowly, so treat it as a snapshot and check a live source for today's exact number. The 21 million cap itself never moves.)

There is an obvious question hiding here: if the reward eventually falls to zero, why would anyone keep mining? The intended answer is fees. As the new-coin reward shrinks, transaction fees are meant to become the main thing miners earn. Whether fees alone will be enough to keep the network secure that far out is a real and openly debated question. Nobody knows for certain.

The waiting room and why fees exist

When you send Bitcoin, it does not go straight into a block. First it waits in the mempool as an unconfirmed transaction until a miner picks it up. It is tempting to picture one single worldwide queue, but that is not quite how it works. Each node keeps its own local pool of the valid, unconfirmed transactions it has heard about. These local pools overlap heavily, so they look similar, but there is no one official global waiting room. Think of it as many nearly-identical waiting rooms rather than a single one.

Here is the catch: a block only has room for so many transactions. When more people want in than there is space, miners have to choose. And they choose the way you would expect anyone paid by tips to choose: they prefer the payments offering the highest fee for the space they take up.

Think of a miner as a taxi with limited room and a line of passengers, each waving a different tip. The driver naturally picks whoever pays the most per seat. If you attach a generous fee, you get into the next block. If you attach a stingy fee during a busy period, you wait, sometimes a long time.

One important detail: the fee is not based on how much money you are sending. It is based on how much space your transaction takes up in a block. That space is measured in virtual bytes (also called weight), a size measure introduced by the 2017 SegWit upgrade. What miners actually rank by is the fee rate: the fee divided by that virtual size. So a payment moving a fortune can be cheap if it is small and simple, and a payment moving pocket change can be expensive if it is large and complicated. You are paying for room on the page, not for the value being moved.

Two features exist to help when you guess the fee wrong:

Bumping the fee lets you resend a stuck transaction with a higher fee to jump the line.
Child pays for parent lets a follow-up transaction attach a big fee to drag a stuck earlier one along with it, since a miner has to include the earlier one to collect the juicy later fee.

What happens when two miners win at once

Sometimes two miners find a valid block at nearly the same moment, in different parts of the world. For a short while, the network disagrees. Part of it heard about block A, part of it heard about block B. This is called a fork, and it is normal and expected, not a crisis.

The tie does not last. Miners keep working, and soon someone builds the next block on top of one of the two. Say the next block lands on top of A. Now the "A" side of the record is longer, and the rule everyone follows is simple: the version with the most work built on it wins. Everyone switches to the longer branch. Block B, the loser, is abandoned, and its transactions (which are almost always also in A) go back into the waiting room to be included normally.

This is exactly why people say to wait for a few confirmations on a big payment. One confirmation means your payment made it into a block. Each additional block stacked on top makes it exponentially harder to ever reverse, because a cheater would have to redo that block and all the ones after it faster than the whole network. For large amounts, waiting for about six blocks (roughly an hour) is the traditional comfort zone.

The "51 percent attack," in plain terms

You may have heard that if someone controlled a majority of the network's mining power, they could attack Bitcoin. That is true, but it is worth being precise about what they could and could not do.

Could do: with the majority of power, an attacker could out-build the honest network and rewrite recent history, which would let them undo one of their own recent payments and effectively spend the same coins twice.

Could not do, even with all that power: steal coins from an address they do not have the key for (they still cannot forge a signature), create coins out of thin air beyond the rules, or change the rules everyone else's nodes enforce. The referees would simply reject anything invalid.

So even the scariest attack is limited, expensive, and easy to notice. It cannot quietly drain your wallet.

Upgrading a system with no boss

If nobody is in charge, how does Bitcoin ever get updated? Carefully, and with the agreement of the people running nodes. There are two flavours of change:

A soft fork tightens the rules in a way that older software still accepts. It is backwards compatible, so it can roll out smoothly. The 2017 upgrade known as SegWit and the 2021 upgrade known as Taproot were both soft forks. They made transactions more efficient and more private without forcing everyone to upgrade on the same day.
A hard fork changes the rules in a way older software will reject. If some people upgrade and some do not, the network can split permanently into two separate coins. This is a much bigger deal and much rarer, because it needs near-universal agreement to avoid a messy divorce.

The short version: Bitcoin can improve, but only by broad agreement, and it strongly prefers changes that do not break anyone who has not upgraded yet.

Going faster: layers on top

Every payment we have described so far gets written into the shared record, checked by every referee on Earth. That is wonderfully secure, but it is not built for buying a coffee. It is a bit like asking the whole world to witness and file paperwork for a $3 purchase.

The common solution is to add a faster layer on top, the best known being the Lightning Network. The idea in plain terms: two people (or a chain of people) open a private tab between them, make as many instant, nearly free payments back and forth as they like, and only write to the main record twice, once to open the tab and once to close it and settle the final total.

It is the same instinct as running a bar tab instead of paying the bank for every single sip. The slow, heavily witnessed main chain becomes the final settlement layer, and the fast layer on top handles the everyday small stuff.

The machines and the electricity question

Early on, people mined Bitcoin on ordinary computers. That did not last. Because mining is just the same fingerprint calculation repeated as fast as possible, hardware makers built chips that do only that one calculation and nothing else, insanely fast. These are called ASICs, and today serious mining happens in warehouses full of them.

This is where the well-known energy debate comes from, and it is worth stating both sides fairly rather than picking one:

The concern: all that guessing burns a genuinely large amount of electricity for a task that, from the outside, produces no physical product. Critics argue that is wasteful and adds to carbon emissions.
The response: supporters argue the electricity is the point, since that real cost is exactly what makes cheating too expensive. They also point out that miners chase the cheapest power, which is often surplus, stranded, or renewable energy that would otherwise go unused, and that plenty of other industries use comparable amounts of energy with less scrutiny.

Both sides have real arguments. Where you land tends to depend on how much value you think a boss-free, tamper-resistant global record actually provides. This guide is not going to settle that for you, and honest people disagree.

A few myths worth clearing up

"Bitcoin is anonymous." Not really. Every payment is public and permanent. Names are not attached directly, but the trail of coins can often be followed and linked to real identities. It is more like writing in a public ledger under a pen name than being invisible.
"A bitcoin is a coin sitting in a file somewhere." No. There is no coin object. There is only the record of which keys control which chunks of value. Owning Bitcoin means holding a key that can sign.
"You have to buy a whole bitcoin." No. Each coin divides into 100 million tiny units, so you can own and send a very small slice.
"Miners approve or reject your payment based on who you are." No. Miners mostly just take the highest fees. The rules are enforced by the referee nodes, not decided by miners' opinions of you.
"If the price crashes, the coins vanish." No. Price is what people will pay. The record of who owns what does not care about the price and keeps working exactly the same either way.

The whole life of a payment, start to finish

Let us tie every layer together by following one payment from the moment you tap send to the moment it is permanent.

Look back at what each step used:

Step 1 is the UTXO model (coins as cash): whole coins in, payment and change out.
Step 2 is a digital signature: the wax seal only you can press.
Steps 3 and 4 are the nodes doing their referee job.
Step 5 is the mempool and fees: the waiting room and the tip.
Steps 6 and 7 are proof of work: the guessing game.
Step 8 is the chain and confirmations: each new block locks the ones below it.

That is the entire machine. Fingerprints at the bottom. Signatures for ownership. Transactions built from signatures. Blocks built from transactions. A chain built from blocks. Agreement built from work. And an economy built on top of all of it.

None of it needs a boss. It needs only a rule that everyone can check for themselves, and a game that makes honesty the cheapest option. That is the quiet, stubborn idea at the centre of Bitcoin.

Next in this series

We have covered why mining works and what the guessing game is. In the next post we will get our hands dirty and actually watch proof of work happen on a real machine, using a mining program called XMRig to make the loop visible and tangible.

Small but important heads-up for later: XMRig cannot mine Bitcoin. Bitcoin mining today needs those special ASIC chips from the hardware section above, not a regular computer's processor. XMRig mines a different, processor-friendly coin. We are using it purely as a clear, hands-on window into the same guess-and-check idea you met here. See you there.

Reference figures (network size, coins mined) reflect roughly mid-2026 and drift over time. The protocol rules (ten-minute target, the halving schedule, the 21 million cap, the block layout) are fixed by the software. When in doubt about a live number, check a public block explorer.

Originally published at devarshi.dev, where all six demos are interactive.

5 Kyverno Policies to Secure Your Kubernetes Cluster

Devarshi Shimpi — Sat, 11 Jul 2026 17:16:41 +0000

Introduction

If you run workloads on Kubernetes, you already know how easy it is for small mistakes to slip into production. A missing resource limit here, a container running as root there, and suddenly your cluster has problems nobody planned for. This is exactly the kind of thing policy as code was built to fix, and Kyverno is one of the easiest tools to start with.

Kyverno is a policy engine built specifically for Kubernetes. Instead of learning a new language to write rules, you write policies in plain YAML, the same format you already use for your deployments and services. That alone makes it a great starting point if you are new to Kubernetes security. Kyverno is also a CNCF Graduated project, which means it has passed a high bar for stability and community trust, and it is already used in production by companies like Spotify, LinkedIn, and Adidas.

In this post, we will walk through five Kyverno policies. We will start simple and end with something a bit more advanced, verifying container image signatures. Each one comes with a small demo so you can see exactly what happens when a policy blocks something. By the end, you will have a solid feel for how Kyverno works and a few policies you can actually use.

Before we get into the policies, here is a quick picture of how Kyverno fits into the request flow. Every time you or your CI pipeline sends something to Kubernetes, Kyverno gets a chance to check it first.

A quick note before we start. Kyverno recently introduced a newer, CEL based way of writing policies, and the classic format used below (ClusterPolicy) is now marked as deprecated in the official docs, though it is still fully supported and works today. It is still the easiest format to learn as a beginner, and this guide points you to the migration path at the end, once you are ready for it.

1. Require Resource Limits

One of the most common problems in a shared cluster is a single pod using up all the CPU or memory on a node. This is often called the "noisy neighbor" problem, and it can slow down or crash other workloads running nearby.

This policy makes sure every pod defines both requests and limits for CPU and memory before it is allowed to run. You can see the full syntax for this kind of rule in the Kyverno validate rules docs.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-requests-limits
spec:
  background: true
  rules:
    - name: validate-resources
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "CPU and memory resource requests and limits are required."
        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    memory: "?*"
                    cpu: "?*"
                  limits:
                    memory: "?*"
                    cpu: "?*"

Once this is applied, any pod that does not set these values will simply be rejected. It is a small rule, but it prevents a lot of headaches later.

Demo: what happens if you skip resource limits

Say you try to apply this pod, which has no requests or limits set.

apiVersion: v1
kind: Pod
metadata:
  name: no-limits-pod
spec:
  containers:
    - name: app
      image: nginx:1.27

kubectl apply -f no-limits-pod.yaml

Error from server: error when creating "no-limits-pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/no-limits-pod was blocked due to the following policies

require-requests-limits:
  validate-resources: 'CPU and memory resource requests and limits are required.
    Validation rule validate-resources failed at path /spec/containers/0/resources/'

Now add the missing fields and try again.

apiVersion: v1
kind: Pod
metadata:
  name: with-limits-pod
spec:
  containers:
    - name: app
      image: nginx:1.27
      resources:
        requests:
          memory: "128Mi"
          cpu: "100m"
        limits:
          memory: "256Mi"
          cpu: "250m"

kubectl apply -f with-limits-pod.yaml
# pod/with-limits-pod created

That's it. The pod goes through as soon as it meets the policy.

2. Block the "latest" Image Tag

It is tempting to just use image: myapp:latest when you are getting started. The problem is that "latest" can point to a different image every time it is rebuilt. This makes deployments unpredictable and makes it very hard to know exactly what version of your app is actually running.

This policy blocks any pod that uses the "latest" tag, or no tag at all.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  background: true
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "An image tag is required."
        pattern:
          spec:
            containers:
              - image: "*:*"
    - name: validate-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "Using a mutable image tag like 'latest' is not allowed."
        pattern:
          spec:
            containers:
              - image: "!*:latest"

This forces every team to use a proper version tag, which makes rollbacks and debugging much easier down the road. This exact example is adapted from the sample policy library that ships with the Kyverno project.

Demo: what happens if you use "latest"

apiVersion: v1
kind: Pod
metadata:
  name: latest-tag-pod
spec:
  containers:
    - name: app
      image: myapp:latest

kubectl apply -f latest-tag-pod.yaml

Error from server: error when creating "latest-tag-pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/latest-tag-pod was blocked due to the following policies

disallow-latest-tag:
  validate-image-tag: 'Using a mutable image tag like ''latest'' is not allowed.
    Validation rule validate-image-tag failed at path /spec/containers/0/image/'

Swap in a real version and the pod goes through without any trouble.

apiVersion: v1
kind: Pod
metadata:
  name: versioned-pod
spec:
  containers:
    - name: app
      image: myapp:1.4.2

kubectl apply -f versioned-pod.yaml
# pod/versioned-pod created

3. Require Labels

Labels are how Kubernetes keeps things organized. They help you filter resources, connect them to monitoring tools, and figure out who owns what. Without labels, a growing cluster turns into a pile of unlabeled boxes nobody can identify.

This policy requires every pod to have a specific label before it can be created. If you want a refresher on what labels are for, the Kubernetes labels documentation is a good place to start.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  rules:
    - name: check-for-labels
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "The label 'app.kubernetes.io/name' is required."
        pattern:
          metadata:
            labels:
              app.kubernetes.io/name: "?*"

You can add more required labels over time, like team name or environment, once this basic rule feels comfortable.

Demo: what happens if a label is missing

apiVersion: v1
kind: Pod
metadata:
  name: unlabeled-pod
spec:
  containers:
    - name: app
      image: myapp:1.4.2

kubectl apply -f unlabeled-pod.yaml

Error from server: error when creating "unlabeled-pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/unlabeled-pod was blocked due to the following policies

require-labels:
  check-for-labels: 'The label ''app.kubernetes.io/name'' is required.
    Validation rule check-for-labels failed at path /metadata/labels/'

Add the label and the same pod is accepted right away.

apiVersion: v1
kind: Pod
metadata:
  name: labeled-pod
  labels:
    app.kubernetes.io/name: myapp
spec:
  containers:
    - name: app
      image: myapp:1.4.2

kubectl apply -f labeled-pod.yaml
# pod/labeled-pod created

4. Restrict Privileged Containers

A privileged container can do almost anything the host machine can do, including accessing other containers and system resources it should never touch. This is one of the biggest security risks in Kubernetes, and it is usually not something you want to allow unless there is a very specific reason for it.

This policy blocks any pod from running in privileged mode. It is also one of the checks covered by the Kubernetes Pod Security Standards, which Kyverno has its own dedicated guide for if you want to enforce the whole standard at once instead of writing individual rules.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  background: true
  rules:
    - name: privileged-containers
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "Privileged mode is not allowed."
        pattern:
          spec:
            containers:
              - =(securityContext):
                  =(privileged): "false"

This is one of the simplest changes you can make that meaningfully reduces your attack surface.

Demo: what happens if a pod asks for privileged mode

apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
    - name: app
      image: myapp:1.4.2
      securityContext:
        privileged: true

kubectl apply -f privileged-pod.yaml

Error from server: error when creating "privileged-pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/privileged-pod was blocked due to the following policies

disallow-privileged-containers:
  privileged-containers: 'Privileged mode is not allowed.
    Validation rule privileged-containers failed at path /spec/containers/0/securityContext/privileged/'

Remove the privileged flag, and the pod is created normally.

apiVersion: v1
kind: Pod
metadata:
  name: safe-pod
spec:
  containers:
    - name: app
      image: myapp:1.4.2

kubectl apply -f safe-pod.yaml
# pod/safe-pod created

5. Verify Container Image Signatures

This last one is a step up in complexity, but it is worth learning because it solves a real problem, how do you know the image running in your cluster is actually the one your team built, and not something tampered with along the way?

This is where image signing comes in. Tools like Cosign, part of the Sigstore project, let you cryptographically sign container images when you build them. Kyverno can then check that signature before allowing the image to run, and reject anything that is not signed or does not match. The full details of this feature are in the Kyverno Sigstore verification docs.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-image-signature
spec:
  background: false
  rules:
    - name: check-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/yourorg/*"
          failureAction: Enforce
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      <your public key here>
                      -----END PUBLIC KEY-----

This is the same idea behind supply chain security, which has become a major topic in the industry after several high profile attacks where malicious code got smuggled into trusted software. Signing and verifying images is one of the clearest ways to close that gap, and it is a great skill to have even if you are still early in your Kubernetes journey.

Demo: what happens with an unsigned image

First, you would sign your image once, when you build it.

cosign sign --key cosign.key ghcr.io/yourorg/myapp:1.4.2

Now if someone tries to deploy an image that was never signed, Kyverno stops it. Note that image verification is handled through Kyverno's mutating webhook, so the error will mention "mutate" rather than "validate" even though the outcome is a rejection.

apiVersion: v1
kind: Pod
metadata:
  name: unsigned-image-pod
spec:
  containers:
    - name: app
      image: ghcr.io/yourorg/myapp:1.0.0

kubectl apply -f unsigned-image-pod.yaml

Error from server: admission webhook "mutate.kyverno.svc" denied the request:

resource Pod/default/unsigned-image-pod was blocked due to the following policies

check-image-signature:
  check-signature: 'image verification failed for ghcr.io/yourorg/myapp:1.0.0:
    signature not found'

Deploy the signed version instead, and it goes through.

apiVersion: v1
kind: Pod
metadata:
  name: signed-image-pod
spec:
  containers:
    - name: app
      image: ghcr.io/yourorg/myapp:1.4.2

kubectl apply -f signed-image-pod.yaml
# pod/signed-image-pod created

Conclusion

None of these policies are complicated on their own, but together they cover a lot of ground: resource limits, image tagging, labeling, privilege restrictions, and image signing. If you are new to Kyverno, a good approach is to start with the first two policies, get comfortable applying them with kubectl apply -f policy.yaml, watch how Kyverno reports violations, and then work your way down the list. You can try all of this without a real cluster using the Kyverno Playground.

Kyverno is actively evolving too. As of version 1.18, the ClusterPolicy style shown in this guide is marked deprecated in the docs in favor of newer CEL based policy types like ValidatingPolicy. It still works fully today and remains the easiest format for a beginner to learn, but once you are comfortable, it is worth reading the guide to migrating to CEL policies to see where the project is headed.

If you want to go further, the official Kyverno documentation has a large library of sample policies you can copy and adapt for your own cluster, and the Kyverno GitHub repository is where the project itself lives if you want to see what is being worked on next.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

I Wanted AI Code Review I Could Actually Own. So I Built Codra.

Devarshi Shimpi — Tue, 23 Jun 2026 21:54:41 +0000

I wanted AI code review I could actually own.

Not access through a subscription or a black-box service with its own limits. The deployment, credentials, providers, and usage under my control.

I kept hitting usage limits mid-week during deep building sessions. The models were capable. The workflow was useful. But access still depended on somebody else's weekly allowance, and centralized platforms can change whenever the company behind them decides to. Pricing, quotas, models, plan boundaries.

A workflow that fits this month may sit behind another subscription next month. I could not find a reliable open-source option that gave me the ownership model I wanted. So I built one.

That became Codra: A self-hosted AI review engine built around bring-your-own models, your own data boundary, and no Codra-imposed usage ceiling.

What Codra Is

Codra is an open-source, self-hosted AI code review engine for GitHub pull requests.

It listens to pull request events, reviews changed files, posts inline findings, and provides a dashboard for jobs, repositories, model routing, history, usage, and failures.

It runs on Cloudflare Workers and uses:

Cloudflare Queues for review jobs
PostgreSQL through Hyperdrive for storage
KV for sessions and cache
A React dashboard for operations

The GitHub App, model credentials, database, and review history are yours. Provider keys are encrypted with AES-GCM using your deployment secret.

Bring Your Own Model, Bring Your Own Limits

Changing providers does not require replacing your review history, configuration, or workflow.

You configure the provider and model. Supported:

OpenAI-compatible APIs
OpenRouter
Anthropic
Google / Gemini
Cloudflare Workers AI

Why Self-Hosted Matters Here

A large frontend repo and a tiny backend repo should not need the same review strategy.

Each repository gets its own review settings. You tune triggers, skip generated files, ignore drafts, use mention-triggered reviews, configure labels, set file limits, and define custom rules.

What Codra Actually Does

Codra is not just a prompt wrapped around a diff.

It includes the pieces needed to operate AI review as a system:

Automatic and mention-triggered reviews
Inline comments, summaries, and check runs
Per-repository rules and skipped paths
Provider fallbacks and size-based model routing
Queue-backed, chunked processing with retries
Dead letter queue recovery
Job history, usage, repository, and model dashboards

The boring pieces are the point.

Production software is mostly unhappy paths: provider outages, malformed output, large diffs, stale jobs, superseded reviews, and failed queue runs.

Codra exists because those details matter.

Open Source Is Part of the Product

Codra is AGPL-licensed because "own your AI review loop" only means something when the system is inspectable.

Developers can inspect how jobs, diffs, prompts, fallbacks, comments, failures, and repository settings work. AI code review is still early, and those questions are better answered in the open:

AI code review is still early. There are open questions everywhere:

Which models work best for different kinds of PRs?
How strict should automated review be?
How should local models and repository context fit in?
How do we reduce noise without missing real bugs?

Those questions are better answered in the open.

Codra should improve through real codebases and community contributions to prompts, providers, docs, tests, and defaults.

What Comes Next

Still in beta, but the foundation is there. The next phase has three tracks.

The next phase has three main tracks.

Deployment Targets

Cloudflare Workers stays the primary target. These paths are for teams and
individuals who want to run Codra on infrastructure they already control.

Vercel Functions adapter and other serverless runtime support
Conventional server deployment via Node.js and PM2 for EC2 or any VM
A Docker-first deployment path for platforms like Hetzner, DigitalOcean, and Coolify

Stability and Developer Experience

The review pipeline works. The focus now is making it hold up under real-world load
and easier to get running without friction.

A more robust pipeline that handles large PRs reliably
Cleaner installation, configuration, and debugging flows for first-time deployers
Community-driven defaults and real-world review config examples

Provider and Model Support

Inference should not be locked to hosted APIs. Local and self-hosted models will
become a first-class option alongside the existing provider list.

Improved support across existing providers
Routes for local and self-hosted models, Ollama, LM Studio, and similar
More language-aware review behavior per file type

Own the Review Loop

Providers, pricing, and quotas will keep changing. Your review engine should not have to change with them.

Codra is open source on GitHub. Try it, star it, break it, file issues, and help shape where it goes next.

Docs: https://codra.run/docs

Voice Search in Chrome Extensions Is Harder Than It Looks

Devarshi Shimpi — Mon, 16 Mar 2026 15:57:17 +0000

I thought this was just an hour of work. It wasn't. Here's everything that went wrong and what actually worked in the end.

Starting with the obvious choice

window.SpeechRecognition is built into Chrome. No API keys, no server, completely free. It felt like the perfect starting point for adding voice search to my extension.
After a day of testing, I dropped it.
The mic permission popup was all over the place. Sometimes it would show up randomly mid-session. Sometimes it would just stop listening with no error, no warning, nothing. Results were different depending on the machine and OS. For a new tab extension that's meant to feel polished, that just wasn't good enough.
I switched to Deepgram's Nova-3 model. It's fast, accurate, and sends results back in real time over WebSocket, so you don't have to wait for a full sentence before seeing any output.
But now I needed a server, which kicked off a whole chain of problems.

Why you can't call Deepgram directly from the extension

Chrome extensions are easy to unpack and read. Any secret you put in the code is basically public. So keeping a Deepgram API key in the client was never going to work.
I needed a server in the middle. My first thought was Railway. I've used it before and getting a Node server running there takes maybe five minutes. But I second guessed that pretty quickly. A server on Railway means it has to start up cold sometimes, it costs money every month, and the speed depends on where the server is located. Cloudflare Workers runs closer to the user since it runs at the edge, and the free plan is generous enough that a voice search API would run for free forever. Easy choice.
The setup I had in mind: the extension sends raw audio to the Worker, the Worker passes it to Deepgram, and the text comes back the same way.

Simple enough on paper. Actually building it was another story.

Hono looked like the right tool. It wasn't.

I use Hono for pretty much everything on Cloudflare Workers. Clean, fast, easy routing. So I reached for it without thinking twice.
Set up a /transcribe route, handled the WebSocket upgrade, deployed it. The Worker just froze. No error from my code, just Cloudflare eventually killing the request with a 500 and a message saying the Worker "would never generate a response."
Took me a while to figure out what was going on. Cloudflare needs a special webSocket property on the Response object to finish a WebSocket connection. That's how it knows which socket to hand back to the client.
Hono wraps the built-in Response to add its own features. Somewhere in that process, the webSocket property gets lost. Cloudflare gets a response with no socket, doesn't know what to do, and kills the request.
The fix was to skip Hono for this route and just write it raw:

export default {
  async fetch(request, env) {
    if (url.pathname === "/transcribe") {
      const pair = new WebSocketPair();
      const [client, server] = pair;
      server.accept();
      return new Response(null, { status: 101, webSocket: client });
    }
  },
};

101 Switching Protocols. Finally.

The timing bug I should've seen coming

Audio was flowing but the Worker kept logging Deepgram not ready. Pretty obvious in hindsight.
The moment the client gets a 101 back, it starts sending audio right away. But the Worker had only just started its own connection to Deepgram. That connection wasn't open yet. So audio was showing up before Deepgram was ready to take it.
My first fix was to wait for the Deepgram connection to open before sending the 101 back:

await new Promise((resolve) => {
  deepgramSocket.onopen = resolve;
});
return new Response(null, { status: 101, webSocket: client });

This worked. But it quietly created a new problem I didn't notice until later.

Cloudflare's 10ms CPU limit is real

The free plan on Cloudflare Workers gives you 10ms of CPU time per request. Not total time, just active processing time. Waiting on a network call doesn't count, so in theory waiting for Deepgram to connect should be fine.
In practice, keeping the request open through the whole connection process added enough overhead that CPU usage was sitting at 40 to 90ms. Cloudflare was going to start dropping requests.

The fix was to stop waiting. Return the 101 right away, let Deepgram connect in the background, and just hold any audio that comes in too early:

let deepgramReady = false;
const pendingChunks = [];

deepgramSocket.addEventListener("open", () => {
  deepgramReady = true;
  for (const chunk of pendingChunks) deepgramSocket.send(chunk);
  pendingChunks.length = 0;
});

server.addEventListener("message", (event) => {
  if (!deepgramReady) {
    pendingChunks.push(event.data);
  } else {
    deepgramSocket.send(event.data);
  }
});

return new Response(null, { status: 101, webSocket: client });

CPU usage dropped to around 2ms. Deepgram still connects, it just doesn't hold everything else up while it does.

AudioWorklet and Manifest V3 don't work together

This was the most painful part of the whole thing.
MV3 extensions only let you run scripts that are part of your own extension package. No inline scripts, no scripts from other websites, nothing generated at runtime. AudioWorkletNode is the standard modern way to process audio in a background thread, and it needs you to load a separate file using addModule(url). You can already see where this is going.

First try was using Vite's ?url import:

import processorUrl from "./processor.js?url";
// Output: data:text/javascript;base64,...

Blocked. Makes sense, data URIs aren't allowed.
Second try was putting the file in the public/ folder and loading it with chrome.runtime.getURL:

const url = chrome.runtime.getURL("audio/pcm-processor.js");
await ctx.audioWorklet.addModule(url);

This really should have worked. A chrome-extension:// URL is from your own extension, so the policy should allow it. I was pretty sure this was the answer.
It failed with AbortError: Unable to load worklet module. No extra info, no useful error message.
After going through Chromium bug reports, turns out this is a known broken behaviour in how Chrome handles extension files in Worklet threads. There are open issues, no fix in sight.

The old deprecated API that actually works

I gave up on AudioWorklet and used ScriptProcessorNode instead. It's been marked as deprecated for years but it runs directly in the page using a callback, so there's no extra file to load and no policy issues. For converting Float32 audio to Int16, the performance hit is basically nothing.

const processor = audioCtx.createScriptProcessor(4096, 1, 1);
processor.onaudioprocess = (e) => {
  const input = e.inputBuffer.getChannelData(0);
  const int16 = float32ToInt16(input);
  ws.send(int16);
};

Works every time without fail. The modern recommended way broke. The old way just works. That's extension development.

A few smaller things worth knowing

Cleaning up properly is harder than it sounds. Web Audio can leak memory if you don't clean up after yourself. When voice search stops, you need to close the WebSocket, disconnect the ScriptProcessor, stop all microphone tracks (this turns off the mic light in the browser toolbar), and close the AudioContext. Skip any one of these and you'll have audio processes running in the background that you can't see.
Silence detection matters a lot. Without it, the mic just stays on forever. Every time Deepgram sends back a transcript or a speech_started event, reset a 2.5 second timer. When the timer runs out, stop listening. It makes the whole thing feel much less annoying to use.
Add the Worker URL to host_permissions in your manifest. You need to allow wss://your-worker.workers.dev/* or the browser blocks the connection before it even gets to any policy check.

What actually changed

Before all of this, the extension was using window.SpeechRecognition with around 500ms before it even started listening, results that changed between machines, and random failures. After the rewrite, it connects in around 100ms, the Worker uses 1 to 3ms of CPU per request, and it works the same way every time.
Every single problem in this build came from the same place: the standard tools weren't built for this environment. Hono breaks WebSockets on Cloudflare. AudioWorklet breaks in MV3 extensions. Once you understand why something fails, the fix is usually obvious. The hard part is getting there.

Happy Coding!!!

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

React (RSC) Exploits Are Real and It's Hurting Engineering Teams

Devarshi Shimpi — Thu, 08 Jan 2026 16:11:01 +0000

If you work in web engineering, the transition into 2026 hasn’t been defined by new features, but by a single, terrifying realization: The boundary between your client and server is broken.

In December, "React2Shell" (CVE-2025-55182) exposed a critical RCE in React Server Components. Barely after teams patched, two more high-severity exploits emerged in the same subsystem. This is the definitive technical post-mortem.

The "React2Shell" RCE (CVE-2025-55182)

To understand why this vulnerability (CVSS 10.0) was so devastating, we first have to understand the machinery it destroyed, the React Flight Protocol.

For years, the mental model for React developers was simple: React renders UI in the browser, and an API (REST/GraphQL) fetches data. The server and client were distinct worlds, separated by a clear network boundary.

React Server Components (RSC) erased that boundary.

In the RSC world, the server doesn't send HTML to the client. It streams a proprietary serialization format called "Flight." This stream contains descriptions of UI components, serialized data, and crucially Promises that resolve to data.

How React2Shell Works

React2Shell was not standard SQL injection or XSS. It was logic abuse targeting a deserializer. Attackers crafted HTTP POST requests with specific "Flight" payloads. These binary-like streams mimicked valid component trees while hiding a "Thenable" Object, or fake Promise.

Injection: Attacker sends serialized object containing malicious __proto__ keys.
Deserialization: Server parses stream and tries resolving fake Promise.
Prototype Pollution: Lack of sanitization lets __proto__ overwrite Object.prototype on running Node.js process.
Gadget Chain: Modified prototype triggers internal calls targeting Function constructor.

Accessing Function constructor means game over. Arbitrary strings like require('child_process').exec(...) compile and execute immediately.

How Next.js was Affected

Because Next.js App Router enables RSC by default, every Next.js application (versions 15.x, 16.x, and canary builds) was vulnerable out of the box. You didn't need to write a buggy Server Action to be hacked. You didn't even need to use Server Components explicitly. If your application booted up react-server-dom-webpack, it was listening for these Flight payloads.

Credits: Next.js for the image

The DevOps Nightmare

For DevOps engineers, "React2Shell" was a worst-case scenario.

WAF Blindness: Standard Web Application Firewalls (WAFs) are trained to look for SQL injection (' OR 1=1) or script tags (<script>). They were not trained to inspect the proprietary text format of React Flight. The malicious payloads passed right through Cloudflare and AWS WAF rules initially.
Supply Chain Hell: The vulnerability wasn't in user code; it was deep in node_modules. You couldn't just "fix the code." You had to wait for Vercel and the React team to release patched binaries, then rebuild and redeploy every single microservice.

The Aftershocks (DoS and Leaks)

Just as engineering teams were recovering from the RCE panic, the security community found more cracks in the foundation. On December 11, 2025, the React team issued a new advisory for three additional CVEs.

While these aren't RCEs, they are operationally devastating and highlight the fragility of the current serialization implementation.

1. Denial of Service (CVE-2025-55184)

Severity: High (7.5/10)

This vulnerability allows attackers to "freeze" infrastructure with a single request.

Mechanism:
Flight protocol allows data chunks to reference other chunks. Researchers discovered they could create circular dependencies in payloads.

Chunk A references Chunk B.
Chunk B references Chunk A.

When the React deserializer attempts to resolve this structure, it enters an infinite synchronous loop.

The Impact on Infrastructure:
Because Node.js is single-threaded, this infinite loop blocks the entire Event Loop.

CPU Spike: The CPU immediately jumps to 100%.
Request Drops: The server stops responding to all other users. Health checks fail.
Cluster Destabilization: In Kubernetes, the liveness probe might fail, causing the pod to restart. But if the attacker sends a stream of these requests, they can put the entire cluster into a "CrashLoopBackOff" state, effectively taking down the application.

Note: The initial fix for this was incomplete, leading to CVE-2025-67779 (the "fix for the fix"), which forced DevOps teams to patch their systems a third time in two weeks.

2. Source Code Leak (CVE-2025-55183)

Severity: Medium (5.3/10)

Arguably most embarrassing vulnerability for React ecosystem. It allows attackers to trick servers into sending source code back to clients.

Mechanism:
Exploit relies on JavaScript string coercion. If Server Action returns object implicitly calling .toString() on a function within server runtime, default V8 behavior returns function source code.

"Secrets" Risk:
Developers often assume code inside use server files is private. They might write:

// DO NOT DO THIS
const STRIPE_KEY = "sk_live_12345"; 
export async function purchase() { ... }

Under normal circumstances, STRIPE_KEY stays on the server. But with CVE-2025-55183, an attacker can manipulate the serialization of the return value to dump the scope of the function, potentially revealing hardcoded API keys, internal comments, and database schema details.

Immediate Action Plan

If you are running Next.js App Router (v13.3+) or React 19, you must execute the following plan immediately:

The "Immediate" Update: Do not trust semantic versioning ranges. Pin your versions to the releases that explicitly fix all discussed CVEs.

npm install react@19.0.2 react-dom@19.0.2 next@15.1.3
# Verify deeply nested dependencies
npm list react-server-dom-webpack

Ensure react-server-dom-webpack is at least version 19.0.2.

Implement Rate Limiting:
The DoS exploit is cheap for attackers. You must implement aggressive rate limiting on all routes, especially POST requests, at the infrastructure level (Nginx, Cloudflare, AWS WAF).
Audit for Secrets:
Assume your server code can be leaked. Run a scan of your app/ directory. If you find a single API key, hardcoded password, or internal IP address in a .ts or .js file, move it to an environment variable immediately.

Conclusion

React Server Components are a powerful evolution of the web, but "React2Shell" has proven that this power comes with a terrifying new attack surface. The Flight protocol is complex, and as we have seen, complexity is the enemy of security.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Dynamic Styling with calc() in TailwindCSS

Devarshi Shimpi — Tue, 14 Oct 2025 22:01:56 +0000

Introduction

TailwindCSS is fantastic, right? It lets us build beautiful, custom designs incredibly fast with its utility-first approach. We grab classes like p-4, flex, w-1/2, and boom – things start taking shape. But sometimes... sometimes you hit a wall. You need a layout element to be exactly 100% wide, minus the fixed width of a sidebar. Or maybe you want padding that dynamically adjusts based on the viewport plus a base value.

In this deep dive, we'll explore how calc() works, why it's such a powerful partner for Tailwind, and how you can leverage it to build more sophisticated, responsive, and pixel-perfect interfaces without ever leaving your HTML (mostly!).

First Things First: What Exactly is `calc()`?

Before we plug it into Tailwind, let's quickly refresh ourselves on what calc() actually does in plain old CSS. At its core, calc() is a native CSS function that lets you perform calculations right inside your property values. Think of it like a mini-calculator for your stylesheets.

It supports the basic arithmetic operations you'd expect:

Addition (+): calc(2rem + 10px)
Subtraction (-): calc(100% - 50px)
Multiplication (*): calc(1.5 * 1rem)
Division (/): calc(100vw / 3)

This ability to blend relative and absolute units is something static values just can't replicate easily.

/* Full width minus a fixed sidebar */
.main-content {
  width: calc(100% - 250px);
}

/* Dynamic padding based on viewport height */
.hero-section {
  padding-top: calc(5vh + 2rem);
}

Why Bring `calc()` into the Tailwind World?

"Okay," you might be thinking, "Tailwind has spacing, sizing, fractions... why complicate things?"

That's a fair question! Tailwind covers a huge range of common styling needs with its utilities. But calc() fills the gaps where:

You Need Mixed Units: Tailwind's w-1/2 is 50%, w-64 is 16rem. But what about calc(50% - 1rem)? Tailwind doesn't have a pre-built utility for every possible mathematical combination.
You Need Precise Dynamic Relationships: Calculating an element's size based on the viewport minus a fixed header/footer height is a prime use case.
You Want Fluidity Beyond Standard Fractions: Maybe a three-column layout needs precise gutters subtracted from fractional widths.
You're Dealing with External Constraints: Sometimes, an element's size needs to account for something outside its direct parent (like the viewport height).

Using Arbitrary Values `[]` with `calc()`

The framework embraced the idea that sometimes, you just need to write a specific CSS value directly. This is done using square brackets []. And guess what? You can put a calc() expression right inside!

The syntax looks like this:

<div class="property-[calc(expression)]">...</div>

Let's see it in action:

Creating a width that's full-width minus some padding:

<div class="w-[calc(100%-2rem)] bg-blue-100 p-4">
  My width adapts, always leaving 1rem of space on each side (total 2rem).
</div>

Setting a height relative to the viewport minus a header:

<header class="h-16 bg-gray-800 text-white">...</header> <main class="h-[calc(100vh-4rem)] bg-gray-100 overflow-y-auto">
  This content area fills the remaining vertical space perfectly.
</main>

Applying dynamic margins or padding:

<div class="mt-[calc(2rem+5vh)] bg-green-100 p-3">
  My top margin grows slightly as the viewport height increases.
</div>

It's that straightforward! You use the Tailwind property prefix (w-, h-, mt-, p-, etc.) followed by your calc() expression wrapped in square brackets.

Let's Get Practical: Real-World `calc()` Scenarios in Tailwind

Theory is nice, but let's see where calc() truly shines in everyday development with Tailwind.

Example 1: The Classic Sidebar + Content Layout

This is a bread-and-butter layout. You have a fixed-width sidebar and want the main content area to take up the rest of the available space.

<div class="flex min-h-screen">
  <aside class="w-64 bg-gray-100 p-4 flex-shrink-0"> Sidebar Content
  </aside>

  <main class="w-[calc(100%-16rem)] bg-white p-6 flex-grow">
    Main Application Content Here...
    It perfectly fills the space next to the sidebar.
  </main>
</div>

Here, w-[calc(100%-16rem)] explicitly tells the main content area to calculate its width based on the full container width minus the sidebar's known width. flex-shrink-0 on the sidebar prevents it from shrinking if space gets tight, and flex-grow on main allows it to expand (though the calc() width often makes this redundant, it's good practice in flex layouts).

Example 2: Making Room for Fixed Headers/Footers

Sticky headers are common, but they can overlap content or require awkward padding. calc() makes managing the space elegant.

<body class="flex flex-col min-h-screen">
  <header class="h-16 bg-indigo-600 text-white p-4 sticky top-0 z-10"> Fixed Header
  </header>

  <main class="flex-grow p-6 bg-gray-50" style="padding-top: calc(4rem + 1.5rem);">
    Content Section
  </main>

  <section class="h-[calc(100vh-4rem)] bg-gray-100 p-6 overflow-y-auto">
     This section takes exactly the remaining viewport height below the header.
  </section>

  <footer class="h-12 bg-gray-700 text-white p-3 mt-auto"> Footer
  </footer>
</body>

In the section example, h-[calc(100vh-4rem)] ensures that specific part of the page uses precisely the vertical space available below the 4rem header. No guesswork needed.

Example 3: Fluid Typography That Breathes

Want your text headings to scale smoothly with the viewport width, not just jump between breakpoints? calc() combined with viewport units (vw) is your friend.

<h1 class="text-[calc(1.5rem+2vw)] font-bold text-gray-900 leading-tight">
  This Headline Scales Fluidly
</h1>
<p class="text-[calc(1rem+0.5vw)] text-gray-700">
  Even paragraph text can subtly adapt to the screen size, improving readability across devices.
</p>

Here, the font size has a base value (1.5rem or 1rem) and adds a small percentage of the viewport width (2vw or 0.5vw). This creates a much smoother scaling effect than relying solely on text-lg, text-xl, etc., at different breakpoints.

Example 4: Precise Centering and Positioning

Sometimes flex or grid centering isn't quite right, especially for absolutely positioned elements or overlays where you need an offset.

<div class="relative h-screen bg-gray-200">
  <div class="absolute top-[calc(50%-50px)] left-[50%] -translate-x-1/2 -translate-y-1/2 bg-white p-8 rounded shadow-lg">
    I'm centered horizontally, but slightly offset vertically!
  </div>
</div>

Here, top-[calc(50%-50px)] positions the element's top edge 50 pixels above the halfway point of the container, while the transform utilities handle the rest of the centering adjustment based on the element's own size.

Going Beyond Arbitrary Values: Custom `calc()` Utilities

Arbitrary values are fantastic for one-offs. But what if you find yourself repeatedly using the same calc() expression? Like that h-[calc(100vh-4rem)] for content below your standard header? Typing that out every time is tedious and error-prone.

This is where extending your Tailwind configuration shines. You can define your own custom utilities that encapsulate these common calculations.

Add this to your tailwind.config.ts:

import type { Config } from 'tailwindcss';

const config: Config = {
  theme: {
    extend: {
      // Example: Add custom height calculation
      height: {
        'screen-minus-header': 'calc(100vh - 4rem)', // Assuming 4rem header
      },
      // Example: Add custom width calculation
      width: {
        'content-area': 'calc(100% - 16rem)', // Assuming 16rem sidebar
      },
      // Example: Add custom spacing
      spacing: {
        'dynamic-gutter': 'calc(1rem + 2vw)',
      }
    }
  },
  plugins: [],
  content: [
    // Ensure your content paths are configured here
    './src/**/*.{html,js,jsx,ts,tsx,vue}',
  ]
};

export default config;

Now, you can use these just like native Tailwind utilities:

<main class="h-screen-minus-header w-content-area p-dynamic-gutter">
  Look Ma, custom calc utilities!
</main>

This makes your HTML cleaner, your calculations consistent, and your design system more robust.

Conclusion

TailwindCSS provides an incredible foundation for rapid UI development. By understanding and integrating the native CSS calc() function through arbitrary values and custom configurations, you unlock a whole new level of dynamic control and precision.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Introduction to Next.js 15: What's New and the improvements!

Devarshi Shimpi — Tue, 17 Dec 2024 05:30:00 +0000

Introduction

Next.js 15 has introduced a range of exciting features and improvements that enhance both performance and developer experience. Here’s a detailed overview of what's new!

Seamless Upgrades with @next/codemod CLI

The enhanced codemod CLI simplifies upgrading to the latest Next.js and React versions. It automates code transformations, ensuring a smooth transition to new APIs and features.

npx @next/codemod@canary upgrade latest

Performance Enhancements

Next.js 15 focuses heavily on improving the speed and efficiency of applications:

Turbopack Boost: Next.js 15's integration with Turbopack accelerates development server startup by up to 53%, providing faster feedback loops.
Hybrid Rendering: Partial prerendering combines static and dynamic content for quicker initial loads and improved user experience.
Enhanced Caching: Optimized caching strategies reduce network requests, resulting in faster load times and predictable data fetching.

Developer Experience (DX) Improvements

Next.js 15 prioritizes the developer experience with several new tools and features:

Asynchronous Request-Specific APIs: APIs for handling cookies, headers, and search parameters have been updated to support asynchronous operations. This change allows for cleaner code and enhances application responsiveness.

New Debugging Tools: Enhanced error messages and stack traces make debugging more efficient, helping developers quickly identify and resolve issues.
New Form Component: A built-in form component simplifies form handling by eliminating the need for third-party libraries. It supports automatic validation, and progressive enhancement, ensuring that forms work even without JavaScript enabled.

import Form from 'next/form';

export default function Page() {
  return (
    <Form action="/search">
      <input name="query" />
      <button type="submit">Submit</button>
    </Form>
  );
}

Experimental Authorization APIs: New APIs for handling authorization errors (forbidden and unauthorized) provide granular control over authentication processes.
TypeScript Configuration Support: Developers can now use TypeScript for their configuration files by renaming next.config.js to next.config.ts. This feature improves type safety and autocompletion, reducing errors during development.

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

Static Route Indicator

Next.js now displays a Static Route Indicator during development to help you identify which routes are static or dynamic. This visual cue makes it easier to optimize performance by understanding how your pages are rendered.

New Middleware Capabilities

A standout feature in Next.js 15 is the introduction of middleware, which allows developers to run code before requests are completed. This is particularly useful for tasks such as authentication and logging.

Support for React 19 and ESLint 9

Next.js 15 officially supports React 19, which introduces several performance optimizations and new features including the new React Compiler.

It also adds support for ESLint 9 while maintaining backward compatibility with ESLint 8. This ensures better code quality through improved linting capabilities tailored for React hooks usage.

Conclusion

Next.js 15 represents a significant advancement in web development capabilities with its blend of performance enhancements, improved developer tools, and robust support for modern React features.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Managing Dependencies and Security in JavaScript with NPM

Devarshi Shimpi — Fri, 09 Aug 2024 13:13:19 +0000

Introduction

The JavaScript ecosystem, particularly with NPM, is both a boon and a bane for developers. On one hand, it provides an incredibly vast library of modules that can accelerate development. On the other hand, it can feel like a tangled web of dependencies, raising legitimate security concerns. Let's dive deep into the intricacies of NPM, the security implications, and how modern bundlers mitigate these risks.

Understanding NPM and Its Ecosystem

NPM is the default package manager for Node.js, which is widely used for server-side and full-stack JavaScript development. It allows developers to easily install, share, and manage code modules.

The convenience it offers has made it a cornerstone of modern JavaScript development. However, with great convenience comes great responsibility.

The Dependency Hell

When you set up a basic project with NPM, you often find yourself pulling in numerous dependencies. Each dependency can have its own dependencies, creating a cascading effect that can quickly spiral out of control. This phenomenon is often referred to as dependency hell.

Consider this scenario: You install a popular library like TailwindCSS. TailwindCSS itself has a few dependencies.

Those dependencies, in turn, have their own dependencies, and so on. Before you know it, your project has hundreds of packages installed, many of which you may not be familiar with. This can make your project more vulnerable to security risks, as it’s challenging to vet each package and its updates.

The Security Concerns

One of the primary security concerns with NPM is the potential for malicious code to be introduced into your project through dependencies. This can happen in a few ways:

Compromised Packages: A legitimate package you depend on might get compromised. This can happen if a maintainer's account is hacked or if the maintainer themselves goes rogue.
Typosquatting: Malicious actors sometimes publish packages with names similar to popular packages, hoping that developers will mistype the name and inadvertently install the malicious package.
Dependency Chains: Even if your direct dependencies are secure, they might depend on other packages that are not. This creates a long chain of trust that can be difficult to manage.

The Polyfill.io Incident

Link to the article here

A recent incident involving a service called Polyfill.io highlighted these risks. Polyfill.io is a CDN service that provides JavaScript polyfills for older browsers. It was discovered that this service could potentially serve different versions of the same script based on the browser's user agent. This variability made it impossible to use integrity checks to verify the script, creating a security vulnerability.

Many websites, including high-profile ones like Hulu, were loading scripts from this service. This incident underscores the dangers of relying on third-party CDNs for critical scripts, as a compromise in the CDN can lead to widespread vulnerabilities.

So, Are We Trading Security for Convenience?

Yes, managing dependencies in a large software project is inherently complex, and no system is foolproof. However, modern package managers, bundlers, and security best practices provide robust safeguards against most common attack vectors.

The key takeaway is this: understand how your tools work. Don't blindly trust; verify. Pin your dependency versions, audit your dependencies regularly, and stay informed about potential vulnerabilities. By adopting a proactive security mindset and leveraging the tools at your disposal, you can reap the benefits of a vibrant package ecosystem without compromising the integrity of your code.

Modern Bundlers to the Rescue

Fortunately, modern JavaScript development has tools to mitigate these risks. Bundlers like Webpack, Vite, and Rollup play a crucial role in ensuring the security and efficiency of web applications.

What is a Bundler?

A bundler takes the various modules and dependencies in your project and combines them into a single file (or a few files) that can be efficiently loaded by the browser. This process not only improves performance by reducing the number of HTTP requests but also helps in managing dependencies more securely.

How Bundlers Improve Security

Local Assets: When you build your project using a bundler, it compiles all your code and dependencies into a single bundle. This means that your application is serving all its JavaScript from your own domain, not relying on third-party CDNs. This significantly reduces the risk of third-party script compromises.
Lock Files: NPM generates a package-lock.json file that locks the versions of all installed packages. This ensures that the same versions are used every time someone installs your project, even if newer versions of the dependencies are released. This consistency is crucial for security.

Integrity Checks: Modern build tools can include integrity checks to ensure that the files served to the browser match the expected hashes. This makes it harder for compromised or altered packages to go unnoticed.

Example with Vite

Let's take Vite, a modern bundler, as an example. When you install dependencies and build your project with Vite, it bundles all the necessary JavaScript files into a single minified file. Here’s a step-by-step of what happens:

Install Dependencies: You install your dependencies using NPM.
Build the Project: You run vite build, which compiles your project.
Serve Local Assets: When you deploy your project, all the JavaScript files are served from your own domain. No external CDNs are involved.

This process ensures that the JavaScript running on your site is exactly what you expect, with no surprises from third-party CDNs.

Addressing Common Misconceptions

There are several misconceptions about NPM and modern JavaScript development that contribute to the fear of security risks. Let’s address some of these:

Misconception 1: NPM Directly Serves Files to Users

Some believe that when users visit a site, they are directly fetching files from NPM. This is not true. NPM is used to manage and install dependencies during the development process. When you build and deploy your project, all the code is served from your own servers, not from NPM.

Misconception 2: Dev Dependencies are Included in Production

Another common misconception is that dev dependencies (packages used for development purposes, like testing or linting tools) are included in the final bundle served to users. This is false. Dev dependencies are only used during development and are not included in the production build.

Misconception 3: Package Lock Files are Unnecessary

Some developers overlook the importance of package-lock.json files. These files ensure that the exact same versions of dependencies are used every time the project is installed, which is crucial for maintaining security and consistency. Without a lock file, there’s a risk of pulling in newer, potentially compromised versions of dependencies.

Best Practices for Secure JavaScript Development

To further mitigate security risks, follow these best practices:

Regular Audits: Regularly audit your dependencies using tools like npm audit to identify and address vulnerabilities.
Lock File Maintenance: Always use and maintain your package-lock.json file. Ensure that your CI/CD pipelines respect the lock file to prevent accidental upgrades.
Dependency Management: Be mindful of the dependencies you add to your project. Avoid unnecessary dependencies and consider the reputation and activity of the package maintainers.
Use Trusted Sources: Prefer well-established libraries and avoid packages with unclear or questionable histories.
Stay Updated: Keep your dependencies up to date with the latest security patches. Tools like Dependabot can automate this process for you.

By taking proactive steps to secure your dependencies and being aware of how your tools work, you can harness the power of NPM and modern JavaScript development while keeping your projects safe and secure.

Conclusion

The NPM ecosystem, with its vast library of packages, undeniably brings convenience to JavaScript development. However, it also introduces potential security risks that cannot be ignored. Understanding how modern bundlers work, maintaining a strict dependency management strategy, and following best practices can significantly mitigate these risks.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

The End of Google URL Shortener and breaks 4.6 BILLION URLs!

Devarshi Shimpi — Thu, 01 Aug 2024 11:18:20 +0000

Introduction

The innovations Google has brought to the table, from Chrome to the Google ecosystem, have undeniably shaped the internet. But sometimes, their decisions leave us scratching our heads, frustrated and disappointed. One such decision is the end of goo.gl, their URL shortener service, which brings back memories of other products they have shelved over the years—like Google Reader and, more recently, Google Domains.

The Rise and Fall of goo.gl

When goo.gl was launched, it was a nifty tool that made sharing long, cumbersome URLs a breeze. It offered analytics and QR codes, making it a favorite among both casual users and developers.

But in 2018, Google announced that it would no longer support the creation of new goo.gl links, nudging users towards alternatives like Firebase Dynamic Links

Fast forward to now, and we've learned that all goo.gl links will completely stop working by August 2025. This isn’t just about not being able to make new links anymore; it means that all existing links will die. Clicking on them after the cutoff date will lead to a 404 error -- a digital dead end.

Alternatives to Google URL Shortener

Google suggested Firebase Dynamic Links as an alternative, but guess what? That service is also being deprecated on August 25, 2025. It's a frustrating loop, recommending one product as a replacement only to kill it off later. It makes planning and continuity a nightmare for users.

As goo.gl sunsets, users are left seeking alternatives. Services like Bitly, TinyURL, and dub.co offer similar functionalities, each service comes with its own set of features, policies, and levels of reliability.

I personally prefer dub.co and it has been great in my experience till now. Their team was quick enough to even make the migration process as seamless as possible! Especially their quick alternative as ggl.link

Conclusion

The decision to end goo.gl is a reminder of the impermanence of digital tools. While Google's decision might be based on practical considerations, the impact on users is real and far-reaching. It disrupts current operations, potentially erases valuable information, and once again highlights the precariousness of relying on a single company for critical digital infrastructure.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

How to create a new Next.js project with Cloudflare Pages and Workers

Devarshi Shimpi — Thu, 18 Jul 2024 14:58:33 +0000

Introduction

In this guide, we'll walk through creating a new Next.js 14 project using TypeScript and deploying it on Cloudflare Pages with Workers for a full-stack solution. We'll use the create-cloudflare CLI (C3) to set up our project, and deploy the application.

Step 1: Create a new Git repository

Go to GitHub, click the "+" icon in the top right, and select "New repository". Set the repository name to nextjs-cf-pages-workers or whatever you would like to, choose Public or Private visibility, and click "Create repository".

Your new repository is now ready! Clone the repository and get ready for the next step!

Step 2: Create a New Next.js Project

To get started, we'll use the create-cloudflare CLI (C3) to create a new Next.js project. Open your terminal and run the following command:

npm create cloudflare@latest my-next-app -- --framework=next

This command initializes a new Next.js project in a directory named my-next-app. Follow the prompts to configure your project. The CLI will install the necessary dependencies, including the Wrangler CLI and the @cloudflare/next-on-pages adapter.

In your terminal, this is how it should look like. After the project is created, navigate to the project directory, and run npm run dev. You should have a browser preview like this:

Step 3: Configure the Project for Cloudflare Pages

You can deploy using mutliple options, I have covered 2 in this article.

Log in to the Cloudflare dashboard and select your account. Navigate to Workers & Pages > Create application > Pages > Connect to Git. Authorize access to your GitHub account and select the new repository you created.

Make sure you have added nodejs_compat as the compatibility flags or the build will fail!

Step 4: Configure and Deploy Without C3

If you prefer not to use C3, you can manually configure and deploy your project. Install the @cloudflare/next-on-pages adapter:

npm install @cloudflare/next-on-pages

Step 5: Set Up Bindings for Local Development

Bindings allow your application to interact with Cloudflare developer products. To set up bindings for local development, modify your Next.js configuration:

// next.config.mjs
import { setupDevPlatform } from '@cloudflare/next-on-pages/next-dev'

if (process.env.NODE_ENV === 'development') {
  await setupDevPlatform()
}

/** @type {import('next').NextConfig} */
const nextConfig = {}

export default nextConfig

Ensure you have a wrangler.toml file at the root of your project with a KV binding:

# wrangler.toml
name = "my-next-app"
compatibility_flags = ["nodejs_compat"]

[[kv_namespaces]]
binding = "MY_KV"
id = "<YOUR_KV_NAMESPACE_ID>"

Alternatively, you can run the following command and it should deploy the project as shown below.

npm run deploy

Success!

By following these steps, you've successfully created and deployed a full-stack Next.js 14 project with TypeScript on Cloudflare Pages and Workers. This setup leverages Cloudflare's powerful developer products to enhance your application's capabilities.

Conclusion

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Managing Metadata in Next.js for Enhanced SEO and User Experience

Devarshi Shimpi — Tue, 02 Jul 2024 11:13:43 +0000

Introduction

In Next.js 14, there are two primary ways to manage metadata for your application: using a static metadata object or a dynamic generateMetadata function. Below is a detailed guide on how to utilize both options effectively.

This guide provides an in-depth look at both approaches, helping you understand how to effectively implement metadata in your Next.js application.

Next.js Demo with Metadata Output

In this live example, we'll create a simple Next.js application showcasing the usage of metadata. Then, we'll view the rendered output in the browser and visualise the metadata in action.

We start by creating a new Next.js project with create-next-app

npx create-next-app@latest

Here's the options I chose while creating it.

Add this sample code in the following block and let's preview it in the browser.

Code:

Output:

And here's the browser output with get with the tags, keep reading the entire article to see how you could implement in your code.

Static Metadata

To define static metadata, you export a Metadata object from a layout.ts or page.ts file using the App Router.

Example:

import { Metadata } from 'next'

export const metadata: Metadata = {
  title: 'Static Page Title',
  description: 'This is a static page description',
}

export default function Page() {}

This method is suitable when the metadata does not depend on runtime information.

Dynamic Metadata

Dynamic metadata allows you to generate metadata based on dynamic data, such as route parameters or fetched data.

Example:

import { Metadata, ResolvingMetadata } from 'next'

type Props = {
  params: { id: string }
  searchParams: { [key: string]: string | string[] | undefined }
}

export async function generateMetadata(
  { params, searchParams }: Props,
  parent: ResolvingMetadata
): Promise<Metadata> {
  const id = params.id
  const product = await fetch(`https://api.example.com/products/${id}`).then((res) => res.json())

  const previousImages = (await parent).openGraph?.images || []

  return {
    title: product.name,
    description: product.description,
    openGraph: {
      images: [product.imageUrl, ...previousImages],
    },
  }
}

export default function Page({ params, searchParams }: Props) {}

This method is useful when the metadata depends on dynamic data or needs to extend parent metadata.

Key Points

Server Components Only: Both metadata and generateMetadata are only supported in Server Components.
Single Export Rule: You cannot export both the metadata object and generateMetadata function from the same route segment.

Metadata Fields

Next.js provides a variety of metadata fields to customize the metadata of your application comprehensively.

Title

String

  export const metadata: Metadata = {
    title: 'Next.js Application',
  }

Output: <title>Next.js Application</title>

Template Object

  export const metadata: Metadata = {
    title: {
      template: '%s | Next.js',
      default: 'Next.js',
    },
  }

Output in child routes: <title>About | Next.js</title>

Absolute

  export const metadata: Metadata = {
    title: {
      absolute: 'About Us',
    },
  }

Output: <title>About Us</title>

Description

export const metadata: Metadata = {
  description: 'The React Framework for the Web',
}

Output: <meta name="description" content="The React Framework for the Web" />

Basic Fields

export const metadata: Metadata = {
  generator: 'Next.js',
  applicationName: 'Next.js App',
  keywords: ['Next.js', 'React', 'JavaScript'],
  authors: [{ name: 'Author Name', url: 'https://example.com' }],
}

Output:

<meta name="generator" content="Next.js" />
<meta name="application-name" content="Next.js App" />
<meta name="keywords" content="Next.js,React,JavaScript" />
<meta name="author" content="Author Name" />
<link rel="author" href="https://example.com" />

Open Graph

export const metadata: Metadata = {
  openGraph: {
    title: 'Next.js',
    description: 'The React Framework for the Web',
    url: 'https://nextjs.org',
    siteName: 'Next.js',
    images: [
      {
        url: 'https://nextjs.org/og.png',
        width: 800,
        height: 600,
      },
    ],
    locale: 'en_US',
    type: 'website',
  },
}

Output:

<meta property="og:title" content="Next.js" />
<meta property="og:description" content="The React Framework for the Web" />
<meta property="og:url" content="https://nextjs.org/" />
<meta property="og:site_name" content="Next.js" />
<meta property="og:locale" content="en_US" />
<meta property="og:image" content="https://nextjs.org/og.png" />
<meta property="og:image:width" content="800" />
<meta property="og:image:height" content="600" />

Twitter

export const metadata: Metadata = {
  twitter: {
    card: 'summary_large_image',
    title: 'Next.js',
    description: 'The React Framework for the Web',
    images: ['https://nextjs.org/og.png'],
  },
}

Output:

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Next.js" />
<meta name="twitter:description" content="The React Framework for the Web" />
<meta name="twitter:image" content="https://nextjs.org/og.png" />

Robots

export const metadata: Metadata = {
  robots: {
    index: false,
    follow: true,
    googleBot: {
      index: true,
      follow: false,
    },
  },
}

Output:

<meta name="robots" content="noindex, follow" />
<meta name="googlebot" content="index, nofollow" />

MetadataBase

metadataBase allows setting a base URL prefix for metadata fields that require a fully qualified URL.

Example:

export const metadata: Metadata = {
  metadataBase: new URL('https://example.com'),
  openGraph: {
    images: '/og-image.png',
  },
}

Output:

<meta property="og:image" content="https://example.com/og-image.png" />

Best Practices

Use Static Metadata When Possible: If metadata doesn't depend on runtime information, prefer static metadata for simplicity.
Dynamic Metadata for Dynamic Data: Use generateMetadata for routes where metadata depends on dynamic data or needs to extend parent metadata.
Combine Metadata Fields: Utilize a combination of different metadata fields to ensure comprehensive metadata coverage for SEO and social media integration.
Utilize metadataBase: Set a metadataBase in your root layout to simplify URL-based metadata field definitions.

Conclusion

By following these guidelines, you can effectively manage metadata in your Next.js 14 application, enhancing both SEO and user experience.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Google's AI-Powered Cloud IDE Project IDX Goes Open Beta!

Devarshi Shimpi — Mon, 10 Jun 2024 09:39:50 +0000

Introduction

At the 2024 Google I/O developer conference, Google unveiled an exciting new tool for developers—Project IDX. Now in open beta, Project IDX is set to revolutionise the way we approach web and mobile app development.

With its AI-powered features and seamless cloud integration, this web-based integrated development environment (IDE) promises to simplify and enhance the development workflow.

What is Project IDX?

Project IDX is a next-generation, web-based IDE that aims to streamline the development process. Built on the popular Code OSS project and leveraging the robust infrastructure of Google Cloud, Project IDX offers a fully configurable virtual machine (VM) environment right in your browser.

For more details and to join the open beta, visit the Project IDX website.

This setup ensures reliability, safety, and complete configurability, making it an ideal choice for developers of all levels.

Making the Most of Project IDX

Get Started Quickly
Start new projects or import existing ones from GitHub effortlessly. Use pre-configured templates and choose from popular frameworks and languages like JavaScript, Dart, and soon Python and Go.
Leverage IDX AI for Enhanced Coding
Utilize IDX AI for intelligent code completion, translations, and explanations of complex snippets, boosting coding speed and quality.
Utilize Built-In Emulators for Mobile Development
Test your mobile apps with built-in Android emulators and iOS simulators, previewing changes in real-time within Project IDX.
Seamless Deployment with Firebase Hosting
Deploy web and Flutter projects directly to Firebase Hosting with a few clicks, ensuring fast, secure, and global hosting.
Collaborate with Ease
Use the experimental collaborative workspace sharing to invite team members, enabling real-time collaboration on code, terminals, emulators, and more.

Conclusion

Google's Project IDX is set to transform the development landscape with its innovative, AI-powered, and cloud-based IDE. Now in open beta, it's the perfect time to explore its capabilities and integrate it into your development workflow.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

DEV Community: Devarshi Shimpi

How the Bitcoin Network Actually Works

What we are actually looking at

The one problem Bitcoin was built to solve

Two pieces of math hold up everything else

Tool 1: the fingerprint machine (a hash)

Tool 2: a lock only you can close, that anyone can check

From a secret number to an address

Blocks, and why they form a chain

Merkle trees: summing up thousands of payments with one fingerprint

Coins are not a balance, they are more like cash

Two different jobs: nodes and miners

Proof of work: the guessing game you cannot cheat

Why almost nobody mines alone

Keeping blocks ten minutes apart, forever

New coins, the halving, and the 21 million limit

The waiting room and why fees exist

What happens when two miners win at once

The "51 percent attack," in plain terms

Upgrading a system with no boss

Going faster: layers on top

The machines and the electricity question

A few myths worth clearing up

The whole life of a payment, start to finish

Next in this series

5 Kyverno Policies to Secure Your Kubernetes Cluster

Introduction

1. Require Resource Limits

Demo: what happens if you skip resource limits

2. Block the "latest" Image Tag

Demo: what happens if you use "latest"

3. Require Labels

Demo: what happens if a label is missing

4. Restrict Privileged Containers

Demo: what happens if a pod asks for privileged mode

5. Verify Container Image Signatures

Demo: what happens with an unsigned image

Conclusion

Read more

I Wanted AI Code Review I Could Actually Own. So I Built Codra.

What Codra Is

Bring Your Own Model, Bring Your Own Limits

Why Self-Hosted Matters Here

What Codra Actually Does

Open Source Is Part of the Product

What Comes Next

Deployment Targets

Stability and Developer Experience

Provider and Model Support

Own the Review Loop

Read more

Voice Search in Chrome Extensions Is Harder Than It Looks

Starting with the obvious choice

Why you can't call Deepgram directly from the extension

Hono looked like the right tool. It wasn't.

The timing bug I should've seen coming

Cloudflare's 10ms CPU limit is real

AudioWorklet and Manifest V3 don't work together

The old deprecated API that actually works

A few smaller things worth knowing

What actually changed

Happy Coding!!!

Read more

React (RSC) Exploits Are Real and It's Hurting Engineering Teams

The "React2Shell" RCE (CVE-2025-55182)

How React2Shell Works

How Next.js was Affected

The DevOps Nightmare

The Aftershocks (DoS and Leaks)

1. Denial of Service (CVE-2025-55184)

2. Source Code Leak (CVE-2025-55183)

Immediate Action Plan

Conclusion

Read more

Dynamic Styling with calc() in TailwindCSS

Introduction

First Things First: What Exactly is calc()?

Why Bring calc() into the Tailwind World?

Using Arbitrary Values [] with calc()

Let's Get Practical: Real-World calc() Scenarios in Tailwind

First Things First: What Exactly is `calc()`?

Why Bring `calc()` into the Tailwind World?

Using Arbitrary Values `[]` with `calc()`

Let's Get Practical: Real-World `calc()` Scenarios in Tailwind

Going Beyond Arbitrary Values: Custom `calc()` Utilities