How do you rack up a $46k Vercel bill - CourtneyR.dev's 2nd Brain

How do you rack up a $46k Vercel bill? 🔗 **Source:** [How do you rack up a $46k Vercel bill?](https://www.youtube.com/watch?v=ihnGot4nUS4) > [!note]+ Document Notes > tags: [vercel, serverless, cost-optimization] > author: Theo - t3.gg > source: YouTube > reference: https://www.youtube.com/watch?v=ihnGot4nUS4 > date created: 2024-12-19 14:30 > > # 🏷️ Title: How do you rack up a $46k Vercel bill? >  ## 🧰 Action Inbox - [H1] Implement aggressive caching strategies — avoid bandwidth costs #cost-optimization - [H2] Consider Cloudflare Workers vs Vercel for high-traffic sites — 7x cheaper requests #platform-selection - [H3] Sample analytics data instead of logging everything — 36% of bill was analytics #monitoring ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Jmail - Epstein Email Interface](URL) - [Vercel Pricing](https://vercel.com/pricing) - [Cloudflare Workers Pricing](https://developers.cloudflare.com/workers/platform/pricing/) ## 📝 Summary - What happened: Jmail creators built a Gmail-like interface for Epstein emails and received a $46k Vercel bill from 650 million page views - Why it matters: Shows how serverless costs can explode with viral traffic and poor optimization - Key stakeholders: Developers using serverless platforms, especially those building viral-potential apps - Risks and tradeoffs: Developer experience vs cost efficiency, caching complexity vs performance - Bottom line: Vercel's great DX comes at a premium; Cloudflare Workers could be 7x cheaper for high-traffic sites ## 📖 Main Content The Jmail project, which created a Gmail-like interface for browsing Epstein's emails, demonstrates how serverless costs can spiral out of control. The $46k bill resulted from four main factors: compute costs, bandwidth usage, request volume, and analytics overhead. While the site handled 650 million page views successfully, the creators made several optimization mistakes including serving uncompressed images, aggressive preloading without proper caching, and logging all analytics data without sampling. Vercel ultimately covered the bill and helped optimize the site. The analysis shows Cloudflare Workers would have been significantly cheaper ($2 vs $0.30 per million requests), though with worse developer experience. The case highlights the classic trade-off between ease of use and cost efficiency in serverless platforms. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/ihnGot4nUS4?t=0) — [H1] $46k Vercel bill breakdown introduction - Key idea: Jmail creators built Gmail interface for Epstein emails and got massive bill - Evidence: "They've taken every single one of the Epstein emails and built this like Gmail interface" #### ⏱️ [01:15](https://youtu.be/ihnGot4nUS4?t=75) — [H2] Four cost categories: compute, bandwidth, requests, add-ons - Key idea: Breaking down serverless costs into main components for analysis - Evidence: "Let's break it down into four sort of categories. You got compute, bandwidth, requests, and like special add-on services" #### ⏱️ [01:45](https://youtu.be/ihnGot4nUS4?t=105) — [H3] Compute costs relatively low due to static content - Key idea: Most content is cacheable JSON that doesn't require heavy processing - Evidence: "Almost all of the content on this website actually is fairly static content" #### ⏱️ [02:30](https://youtu.be/ihnGot4nUS4?t=150) — [H2] Images hosted separately on Cloudflare - Key idea: Smart move to offload images to cheaper CDN with transformations - Evidence: "Most of the images on here are probably are not even part of that Vercel bill because they're hosted totally separately" #### ⏱️ [03:15](https://youtu.be/ihnGot4nUS4?t=195) — [H1] Unoptimized assets causing bandwidth waste - Key idea: Half-megabyte uncompressed Facebook icon shows poor asset optimization - Evidence: "This biggest one right here is over half a meg for a little icon that's being loaded here" #### ⏱️ [04:00](https://youtu.be/ihnGot4nUS4?t=240) — [H2] Aggressive preloading trades cost for performance - Key idea: Site preloads content on hover for fast experience but uses more bandwidth - Evidence: "They are aggressively loading them all in... it's faster than Gmail. This is a very good experience" #### ⏱️ [05:30](https://youtu.be/ihnGot4nUS4?t=330) — [H3] Cloudflare added as cache layer after bill - Key idea: Caching was implemented post-incident to reduce future costs - Evidence: "I don't know if this happened before or after the $46,000 bill, but you'll see here they did throw Cloudflare in front of Vercel" #### ⏱️ [06:15](https://youtu.be/ihnGot4nUS4?t=375) — [H1] Request volume compounds with traffic - Key idea: 500 requests per visitor multiplied by 650M views creates massive costs - Evidence: "500 requests, three and a half megs... 650 million page views. That's a lot of page views" #### ⏱️ [07:00](https://youtu.be/ihnGot4nUS4?t=420) — [H2] Vercel pricing: $2 per million requests, 15¢ per GB - Key idea: Specific pricing breakdown shows how costs accumulate - Evidence: "Vercel's ondemand bandwidth is 15 cents per gig... $2 per 1 million edge requests" #### ⏱️ [08:00](https://youtu.be/ihnGot4nUS4?t=480) — [H1] Analytics comprised 36% of total bill - Key idea: Web analytics became the largest single cost component - Evidence: "36% of the bill was simply from web analytics... $2 per 1 million... that adds up very quickly" #### ⏱️ [08:45](https://youtu.be/ihnGot4nUS4?t=525) — [H2] Sampling recommended for high-volume analytics - Key idea: Don't need 100% data capture at scale, similar to Sentry error tracking - Evidence: "Sampling is probably a good approach here... 50% of that or 25% of that will be enough" #### ⏱️ [10:00](https://youtu.be/ihnGot4nUS4?t=600) — [H1] Cloudflare Workers significantly cheaper - Key idea: Cloudflare offers 7x cheaper requests and mostly free bandwidth - Evidence: "$2 per 1 million requests versus 30 cents on Cloudflare" #### ⏱️ [11:30](https://youtu.be/ihnGot4nUS4?t=690) — [H2] Vercel wins on developer experience despite cost - Key idea: Better tooling and DX justify higher costs for many developers - Evidence: "The Vercel DX is the best... the tooling on Vercel is significantly better" #### ⏱️ [12:30](https://youtu.be/ihnGot4nUS4?t=750) — [H3] VPS would have crashed under load - Key idea: Traditional hosting couldn't handle viral traffic without complex scaling - Evidence: "This site would have definitely have crashed on a VPS or have had a hug of death" ## 📚 References - [Vercel Pricing Documentation](https://vercel.com/pricing) - [Cloudflare Workers Pricing](https://developers.cloudflare.com/workers/platform/pricing/) - [OpenNext Project](https://open-next.js.org/) ## 🗣️ Paraphrase - A viral email browsing app accumulated a $46k hosting bill due to poor optimization and massive traffic - The main cost drivers were unoptimized assets, aggressive preloading, high request volumes, and comprehensive analytics logging - Cloudflare Workers would have been significantly cheaper but with worse developer tooling and experience ## 📰 Newsletter The recent $46k Vercel bill story offers valuable lessons for WordPress developers about serverless cost management. While WordPress hosting is typically more predictable, the principles of optimization matter just as much. Key takeaways: optimize your images (WordPress handles this well with WebP support), implement proper caching strategies, and be mindful of analytics overhead. For high-traffic WordPress sites, consider CDN solutions and don't log every single event. The trade-off between developer experience and cost mirrors WordPress hosting choices - managed WordPress hosting costs more but offers better DX than managing your own VPS. Resources: [WordPress Performance](https://make.wordpress.org/core/handbook/best-practices/performance/), [Caching Guide](https://developer.wordpress.org/advanced-administration/performance/caching/), [CDN Integration](https://wordpress.org/plugins/search/cdn/) ## ✅ Action Items #### DevRel - Developer advocacy: Create cost optimization workshops, "bill shock" prevention talks - Education: Develop serverless cost calculator tools and optimization curricula - Developer experience: Document cost monitoring best practices, SDK cost warnings - Developer marketing: Case studies comparing platform costs vs developer experience - Community management: Cost optimization discussion forums, bill review sessions #### WordPress - Core Performance: Image optimization defaults, lazy loading improvements - Documentation: Cost optimization guides for WordPress hosting platforms - Hosting: Cross-platform cost comparison tools, optimization recommendations ## 🧪 Hypotheses - Aggressive preloading increases user satisfaction but exponentially increases costs at scale - Developer experience quality is inversely related to cost efficiency in serverless platforms - Analytics sampling at 25% provides sufficient insights while reducing costs by 75% - CDN-first architecture can reduce serverless bills by 60-80% for content-heavy sites ### 📊 Methodology - A/B test preloading strategies with cost tracking and user experience metrics - Survey developers on willingness to trade DX for cost savings at different price points - Implement progressive sampling rates and measure analytics accuracy vs cost reduction ### ❓ Questions - What's the optimal preloading strategy that balances UX and cost? - How much developer productivity loss is acceptable for 50% cost savings? - When do VPS solutions become more cost-effective than serverless platforms? ### 🔮 Future Research - Real-time cost monitoring and automatic scaling adjustments for serverless - ML-driven prediction of viral traffic patterns for proactive optimization - Cross-platform migration tools for moving between serverless providers ### 💡 Implications - Practice: Implement cost monitoring from day one, not after traffic spikes - Policy: Establish cost thresholds and automatic scaling limits for projects - Security: Cost-based DDoS attacks become viable on poorly optimized serverless apps - Education: Developer training must include cost optimization, not just functionality - Funding: Budget for viral success scenarios, not just expected traffic ### 🧠 Learning Styles Assessment Reading level estimate: 8th Grade (Flesch-Kincaid) #### 👀 Visual learners - Present: Screenshots of developer tools, billing breakdowns, performance metrics - Improve: Cost comparison charts, traffic spike visualizations, architecture diagrams #### 🔊 Aural learners - Present: Video format with clear narration and explanations - Improve: Podcast-style deep dive on cost optimization strategies #### 🗣️ Verbal learners - Present: Clear technical definitions, platform comparisons, analogies to traditional hosting - Improve: Story-driven examples of other viral apps and their cost challenges #### 🧩 Kinesthetic learners - Present: Code examples, configuration screenshots, hands-on platform exploration - Improve: Interactive cost calculator, step-by-step optimization checklist #### 🧠 Logical learners - Present: Clear pricing breakdowns, mathematical calculations, cause-effect relationships - Improve: Decision trees for platform selection, cost-benefit analysis frameworks #### 🧑‍🤝‍🧑 Social learners - Present: Community discussions about platform choices, shared experiences - Improve: Developer forums for cost optimization strategies, collaborative optimization reviews #### 🧘‍♀️ Solitary learners - Present: Detailed technical analysis for independent study - Improve: Self-assessment tools for cost optimization, personal project worksheets #### 🌿 Naturalistic learners - Present: Platform ecosystem comparisons, technology evolution patterns - Improve: Sustainability angles of efficient resource usage, environmental impact ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Good heading structure, descriptive link text for platform comparisons - Improve: Alt text for cost charts, ARIA labels for interactive calculators #### Keyboard navigation - Present: Standard video controls, focusable timestamps - Improve: Skip links for long technical sections, keyboard shortcuts for code examples #### Contrast and readability - Present: Clear text on video, readable code snippets - Improve: High contrast mode for cost charts, larger text options for detailed pricing #### Text resizing and reflow - Present: Responsive design works at 200% zoom - Improve: Ensure code blocks don't overflow, maintain readability at high zoom #### Media and captions - Present: Video with clear audio, transcript provided - Improve: Enhanced captions with speaker identification, downloadable transcript #### Forms and interactions - Present: Basic video interactions accessible - Improve: Accessible cost calculator forms, clear error states for invalid inputs ### 🌍 DEIB Assessment #### Cultural breadth - Present: US-focused pricing examples and platforms - Improve: International pricing comparisons, global developer perspectives #### Inclusive language - Present: Gender-neutral technical terms, clear jargon definitions - Improve: Plain language summaries, avoid cultural idioms like "grandma's basement" #### Neurodiversity support - Present: Clear section breaks, consistent structure - Improve: Content warnings for financial stress topics, summary bullets #### Representation - Present: Focus on technical content over individual representation - Improve: Diverse case studies beyond tech industry, varied company sizes #### Psychological safety - Present: Non-judgmental analysis of expensive mistakes - Improve: Emphasize learning from failures, provide supportive resource lists ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong mathematical analysis of pricing structures and cost breakdowns - Inductive strength: Good generalization from specific case to broader serverless principles - Causal reasoning: Clear cause-effect relationships between optimization choices and costs - Analogical strength: Effective comparisons between platforms and traditional hosting #### Fallacies - False dichotomy: Presents VPS vs serverless as binary choice, ignoring hybrid approaches - Hasty generalization: Assumes all high-traffic sites will have similar cost patterns #### Tone of voice - Overall tone: Informative and analytical with casual, approachable delivery style ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on individuals or organizations - Reverse victim/offender: No victim/offender dynamics present - Emotional cues: Balanced analysis without inflammatory language, acknowledges trade-offs fairly ## 🎯 Conclusion The $46k Vercel bill demonstrates that serverless platforms offer excellent developer experience at the cost of potential bill shock during viral traffic. The key lesson is implementing cost monitoring and optimization from the start, not after problems arise. While Cloudflare Workers could have been 7x cheaper, the developer experience trade-offs matter significantly for shipping products quickly. The incident highlights the importance of understanding your platform's pricing model and having contingency plans for unexpected traffic spikes. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] Server --- ## Full Transcript [00:00] $46,000 [00:02] Versel bill. How does that possibly [00:05] happen? This was the creators of Jmail. [00:07] They've taken every single one of the [00:09] Epstein emails and built this like Gmail [00:12] interface so you can sort of click [00:14] through and read them and load them and [00:16] filter them by different people. It's a [00:19] really sick website, but they've racked [00:21] up a $46,000 Versel bill. I have large [00:24] sites running on Verscell, Cloudflare, [00:26] and VPS. And I did some quick back of [00:28] the napkin math and I think I know where [00:30] most of this bill went to and we're [00:32] going to break it down so hopefully it [00:34] doesn't happen to you as well. Let's [00:36] break it down into four sort of [00:37] categories. You got compute, bandwidth, [00:40] requests, and like special add-on [00:42] services, right? So compute is is when [00:44] your application actually needs to run [00:46] some processes, right? Whether it's it's [00:47] fetching data from the database or [00:49] looping over arrays, um whether it's [00:51] handling a URL and routing it to [00:53] wherever you go. That is when your [00:56] server actually needs to do work. And [00:59] almost all of the content on this [01:01] website actually is fairly static [01:04] content, right? If you if you go ahead [01:05] and look at a lot of these requests that [01:07] are coming in, you'll see that it's it's [01:09] just JSON that's that's coming in, [01:11] right? So, it's it's just text. Text can [01:13] be cached very heavily. The stuff on [01:15] here is not changing very often. The [01:17] guy's dead, right? He's not sending any [01:19] more emails. Well, I guess that's maybe [01:20] up for debate, but uh there's a lot of [01:24] stuff that can be be cashed on here. So, [01:26] I don't know. It it certainly is [01:28] probably a big expense here, but [01:30] probably not the biggest one because [01:32] they're not doing things like um they're [01:34] not OCRing on demand. They're they're [01:36] not doing any really heavy intensive [01:39] stuff. They are simply just rendering [01:41] out React elements on a page and then [01:43] caching those heavily. So, the next one [01:45] is bandwidth. And this is probably a big [01:47] one, but not what you might think, [01:49] right? You think like, oh, images and [01:51] and whatnot. So, if you go to one of the [01:53] images that are on this website, you'll [01:55] see that they are hosted on a totally [01:57] separate domain name. And this this URL [01:59] here and and the header looking at the [02:00] headers tells me they're using [02:01] Cloudflare image transformations to [02:04] resize them. So, they're they're not as [02:05] big to load on on page load and and [02:07] they're not um using up as much [02:09] bandwidth. Most of the images on here [02:11] are probably are not even part of that [02:13] Versel bill because they're they're [02:15] hosted totally separately. But if we go [02:17] let's go to this homepage here, do a [02:19] hard refresh and then sort them by size, [02:22] you'll see there are some things that [02:23] are being hosted on this. This biggest [02:25] one right here is over half a meg for a [02:28] little uh icon that's being loaded here. [02:31] If we open that up in a new tab, it's [02:34] just a little Facebook icon, not [02:36] compressed at all and probably way [02:38] larger than it needs to be and probably [02:40] could be in SVG. So, serving that up. [02:43] Plus, there are several other like uh [02:46] images that are being loaded in here and [02:49] adding adding all those up, it's it's [02:51] about a meg plus you're looking at all [02:54] of the JavaScript and CSS bundles that [02:56] are being loaded up. That's probably [02:58] close to another meg as well. So every [03:00] single person visiting the website fresh [03:03] cache you're they're using two megs of [03:05] bandwidth which is is is quite a bit. [03:08] Then the other part of the bandwidth [03:11] here is this aggressive preloading. Um [03:14] so if I go to my dev tools I'm going to [03:17] filter for XHR and then as I simply just [03:22] scroll you'll see that there's like tons [03:24] of requests being being fired off. Now, [03:28] I have my cache disabled here, so they [03:30] are loading from my disc cache. But the [03:32] first time that you hover over top of [03:33] those, you'll see it's just a bunch of [03:35] JSON being loaded, but they are [03:37] aggressively loading them all in. Now, [03:40] that is a very high trade-off. And I did [03:43] a video about how McMaster car does this [03:45] as well. Um, because now when you when [03:48] you click on some of these, they load [03:50] extremely fast. Quite honestly, it's [03:52] faster than Gmail. This is a very good [03:54] experience. So you are you have a bit of [03:57] a trade-off where yeah I will [03:59] aggressively preload everything in even [04:02] though we might not use that but you are [04:04] giving them a really nice experience but [04:07] that's not free sending all of this JSON [04:09] over the wire still use quite a bit of [04:12] bandwidth. Now you're probably screaming [04:14] right now mean like that's just text. [04:15] That's static text that probably does [04:17] not change very often. You can cash the [04:19] crap out of that. And that's exactly [04:21] what they're doing. I don't know if this [04:22] happened before or after the $46,000 [04:25] bill, but you'll see here they did throw [04:27] Cloudflare in front of Verscell, which [04:29] Verscell doesn't really like you doing, [04:31] but uh you can see that there is a cache [04:34] status of hit here, meaning that that [04:37] should now not go past Cloudflare and [04:41] then send the request to Verscell, which [04:44] which would then incur them bandwidth as [04:47] well as which we'll talk about next is [04:50] request. I think that that was added [04:52] after, but you'll see there is a pretty [04:53] aggressive 30-day and 7-day stalewhile [04:56] validate. So, that brings me to the next [04:57] one, which is simply just paying for [04:59] requests. So, the way that a lot of [05:01] these serverless platforms work is that [05:04] they will charge you for how much um [05:06] time you are using um in compute, but [05:08] then they will also charge you based on [05:10] how many requests you are sending them. [05:12] And because you you load the page up [05:14] here, you get I don't know 50 requests [05:16] to different parts of it. you know, [05:18] you're you're loading in JavaScript and [05:19] CSS and then there's um some React [05:21] server components that need to load in [05:23] different requests. And then of course [05:25] once you start hovering over all of [05:27] these things that just fires up the [05:28] amount of requests. So you spend a [05:30] minute or so kind of just looking [05:32] around, hovering over things, clicking [05:33] on different emails, you get up to 500 [05:36] requests fairly quickly. And in this [05:39] case, it's just over a meg. If you load [05:41] a couple emails, I was able to get it up [05:43] to about about three megs worth of it. [05:45] So, if you're doing some some quick math [05:48] on that, you know, 500 requests, three [05:50] and a half megs um for an average [05:52] visitor just visiting for a minute or [05:54] so, um Versel's ondemand bandwidth is is [05:58] 15 cents per gig here. Um and then it [06:02] also is $2 per 1 million edge requests. [06:06] So, if you're looking at me doing, I [06:09] don't know, 500 requests, three and a [06:10] half megs, um, that would cost them a [06:14] tenth of a penny. That's not much, [06:16] right? A tenth of a penny. That that's [06:18] that's almost nothing. But remember what [06:20] they're doing here. 650 [06:23] million page views. That's a lot of page [06:26] views. Um, that will add up. My math [06:28] shows me that like without any sort of [06:30] cashing or anything in front of it, that [06:32] could be hundreds of thousands of [06:34] dollars. Obviously, the bill wasn't [06:35] hundreds of thousands of dollars because [06:36] of the what they've done to implement [06:39] the cash there, but that simply will add [06:42] up. Those tenth of a pennies add up. [06:44] Now, the next one, which is like [06:46] add-ons. So, they actually Versel [06:50] stepped up and said, "Yeah, like we'll [06:51] cover the bill." Which was really cool [06:52] of them. Um, and then they went through [06:54] it and said like, "Yeah, like we're [06:56] going to figure out how to how to get [06:57] this thing as cheap as possible." And it [07:00] turns out 36% of the bill was simply [07:04] from web analytics. Um so what pages do [07:08] people visit? Uh like where are they [07:11] coming from? What browser? You know, you [07:12] know, all of that stuff that you get in [07:14] analytics. But the thing that sort of [07:16] killed them here is that they were I [07:18] guess the analytics double dip on the [07:20] request. So, you're paying for [07:22] analytics, but then you're also paying [07:24] for those requests, um, those edge [07:27] requests that are going in there. And if [07:29] you take a look here, remember $2 per 1 [07:32] million. And if you're logging all kinds [07:34] of of data being sent over here, that [07:37] that adds up very quickly. So, GMO goes [07:40] on to mention that like sampling is [07:42] probably a good approach here. Um, and [07:44] this is exactly what Sentry does as well [07:46] is if if you were you can send every [07:49] single every error that happens on your [07:51] website to Sentry. But if you have [07:54] enough traffic, that's likely too much [07:57] and it's you don't necessarily need all [07:59] of that data at super high volume. So [08:01] what you can do is just sample those and [08:03] you still get all of the information [08:05] that you're looking for. You don't need [08:06] to know that what 50,000 people had like [08:10] a a missing undefined variable on there. [08:13] um simply 50% of that or 25% of that [08:17] will be enough. Processing and storing [08:19] data is is not cheap. My personal [08:22] opinion, 17 grand for analytics seems [08:25] extremely high, but I think we all got [08:28] used to to using Google Analytics as a [08:31] as a free product. We didn't realize how [08:33] expensive holding, processing, storing [08:36] all of that data actually is. Now, the [08:38] question is is would Cloudflare be [08:40] cheaper? Right? So we sort of know what [08:43] the big costs were here, right? There [08:44] was bandwidth, there was requests, and [08:46] then there was those those analytics [08:48] being added on here. So let's go through [08:50] it. So Versell and Cloudflare both have [08:52] the ability to charge based on what's [08:54] called CPU time. You have an 800 se 800 [08:57] millisecond serverless function that's [08:59] running, but maybe you're only using 50 [09:02] milliseconds, 30 milliseconds of that to [09:04] do actual compute. You're looping over [09:06] an array. You're creating objects. You [09:08] have classes. things like that is is [09:10] actual compute. Whereas like if you send [09:13] off a fetch request and you're waiting [09:15] 200 milliseconds for like an AI to [09:18] respond, you don't have to pay for that [09:20] time, which is is really cool. That's [09:22] different from traditional serverless [09:24] where you're simply just paying for the [09:26] time that that thing is running. So [09:28] Cloudflare calls that wall time um [09:30] versus CPU time and Versell calls that [09:33] fluid compute. Next one is bandwidth. [09:36] Cloudflare is mostly free. Everybody [09:39] likes to say Cloudflare is the bandwidth [09:40] is free and and that is is mostly true. [09:43] But um for the images that they're [09:45] they're hosting on Cloudflare here, you [09:47] certainly pay for for that product and [09:49] you pay to hold those images. You pay [09:51] based on number of transformations that [09:53] you use, the number of requests that [09:54] that go to that. But things like um your [09:58] CSS, your your JavaScript um those sort [10:03] of static assets that can be cached, you [10:06] don't pay for for bandwidth on those [10:08] types of things, which is is really [10:10] really nice. So that would have [10:11] significantly decreased their bill, [10:13] especially for their um 650k [10:16] little logo that they have here. Next [10:19] one is request. So, this is kind of a [10:22] kind of a weird one because if you put [10:25] Cloudflare in front of an existing [10:29] website, maybe you host it on like a VPS [10:31] or maybe you host it on Verscell and you [10:32] throw this cache control header and the [10:35] CDN cache control header on there. What [10:38] that will do with Cloudflare is [10:41] Cloudflare will simply just serve up the [10:43] cache version. However, if you are [10:45] programmatically doing your cache as [10:46] part of your worker um or if you are [10:49] hosting your entire website on a worker, [10:52] you it still hits your worker on [10:54] Cloudflare and you still pay for that [10:57] request to Cloudflare even if you simply [10:59] are um serving up. I I hit this with my [11:02] own personal websites like that seems [11:04] higher. I was trying to cache entire [11:07] HTML pages, but because my entire site [11:10] was inside of a worker, even though I [11:12] was serving up the cache version of that [11:14] HTML, I still paid for that request to [11:17] there. But let's talk about the actual [11:20] prices of this thing. So requests on [11:22] Cloudflare are [11:24] um you get 10 million a month and then [11:26] 30 cents per million and then your CPU [11:30] time, you get 30 million CPU [11:32] milliseconds. Essentially, this works [11:35] out to being 7.2 cents per hour. Um, [11:39] that's not like you don't take 7.2 cents [11:42] and multiply by 24. That's just [11:44] basically how much time those processes [11:47] are running. Taking a look at Versell, [11:50] um, we we saw this already, $2 per 1 [11:52] million requests versus 30 cents um, on [11:55] Cloudflare. And then CPU time is about [11:59] 12 cents uh, 13 cents an hour. So [12:01] between those three things, [12:03] significantly cheaper CPU time, um [12:06] significantly cheaper bandwidth or or [12:08] free bandwidth in in many cases, um and [12:10] then also significantly cheaper [12:12] requests. You probably would have been a [12:14] lot lower. There's a lot to be said for [12:17] Cloudflare here. Um and the reason why [12:19] not absolutely everybody is on [12:21] Cloudflare is because the Versel DX is [12:24] the best. Um and I say this as someone [12:26] who absolutely loves Cloudflare. I've [12:28] got many gripes with it. Like the other [12:30] day we couldn't get logs for a preview [12:32] of URLs. You can't get custom domains [12:34] for preview URLs. Having like staging in [12:36] production is a pain in the butt. [12:38] There's lots of things which on Verscell [12:41] sharing um I couldn't share a worker [12:43] with somebody. The the solution to was [12:45] move the entire domain and worker to a [12:47] different Cloudflare account and then [12:49] you can share that entire account with [12:52] somebody else. So the tooling on [12:54] Verscell is significantly better. But a [12:57] lot of people will simply just say um [13:00] I'm I'm okay with with a little bit of [13:03] pain or figuring out these oddities on [13:05] Cloudflare for the price. Now analytics. [13:07] Cloudflare has free web analytics. As [13:09] far as I can tell, they are at feature [13:11] parody and I don't think that they count [13:14] towards your actual requests and you [13:16] don't have to pay for them. So that that [13:18] again $17,000 that that would have been [13:21] saved. Now, what about a VPS? Could you [13:24] have done this on a $5 a month uh like [13:27] digital ocean? Could you host it in your [13:29] grandma's basement? That type of thing [13:32] maybe with you would certainly have to [13:35] put an aggressive cache in front of it. [13:38] And you would have to set up [13:39] autoscaling, load balancing, all of that [13:41] type of stuff. So, um I don't know like [13:43] render railway, these types of things. [13:45] they for $46,000 you can let those [13:48] things scale up to 7 8 n 10 different [13:51] instances for for quite a bit cheaper [13:54] than than 46k. But the thing that people [13:58] aren't talking about with these VPS's is [14:00] that like you still need a CDN in front [14:03] of these things that will handle all of [14:06] your caching because bandwidth coming [14:08] from a VPS is is extremely expensive. [14:11] So, my thoughts here, one, this bill [14:13] would not have been nearly as large on [14:16] Cloudflare. Two, this site would have [14:18] definitely have crashed on a VPS um or [14:21] have had a hug of death from it, right? [14:23] There's always that thing like, should [14:24] you go down or should you pay more when [14:26] you get these crazy spikes in traffic? [14:28] And then third, this site and many other [14:31] people's hobby projects may not have [14:33] launched if it wasn't for Versel. Versel [14:36] has made this stuff super easy to sort [14:38] of just publish and out there. However, [14:41] we hear these stories all the time where [14:43] something gets popular and somebody [14:45] goes, "Shoot, I this thing is costing [14:47] way more than I thought it would." [14:49] Everything in life is a trade-off. [14:51] There's Open Nex where you can host Next [14:53] Nex.js on Cloudflare. Not perfect. I [14:55] tried it myself for quite a while and I [14:56] ended up just scrapping Nex entirely, [14:58] moving to Wacku. But build on tech that [15:01] can be moved absolutely anywhere. So [15:03] that if something like this happens to [15:05] you and you have the fortune of having [15:08] an extremely popular website, hopefully [15:09] it's not going to cost you an arm and a