Where Should You Deploy In 2026 - CourtneyR.dev's 2nd Brain

Where Should You Deploy In 2026? 🔗 **Source:** [Where Should You Deploy In 2026?](https://www.youtube.com/watch?v=yfxDdQo2cyI) > [!note]+ Document Notes > tags: [deployment-platforms, devops, cloud-hosting] > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=yfxDdQo2cyI > date created: 2024-12-19 10:30 > > # 🏷️ Title: Where Should You Deploy In 2026? >  ## 🧰 Action Inbox - [H1] Evaluate serverless-first approach — most apps fit serverless model — 00:00 #deployment - [H2] Consider bandwidth costs carefully — can drive unexpected bills on Vercel — 15:45 #cost-optimization - [H3] Avoid Hetzner for production — reliability and support issues — 22:30 #platform-selection ## 🧭 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 - [Vercel](https://vercel.com) - [Railway](https://railway.app) - [Render](https://render.com) ## 📝 Summary - Comprehensive comparison of deployment platforms for 2026, covering serverless and VPS options - Recommends starting with serverless solutions (Vercel, Railway, Render) for 98% of applications - Key factors: developer experience, cost transparency, reliability, and platform longevity - Top tier recommendations: Railway, Vercel, Render based on overall value - Warning against platforms with poor support (Hetzner) or confusing pricing (AWS for small teams) ## 📖 Main Content This analysis breaks down deployment platform choices into serverless and VPS categories, with detailed evaluation of developer experience, pricing, reliability, and business sustainability. The recommendation strongly favors serverless-first approaches, as most applications can be successfully deployed without traditional servers. The evaluation considers both technical capabilities and business factors like platform longevity, noting recent industry consolidation and the risk of platforms disappearing. Particular attention is paid to hidden costs like bandwidth charges and seat pricing that can dramatically impact total cost of ownership. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/yfxDdQo2cyI?t=0) — [H1] Introduction and Approach - Key idea: Breaking down deployment options into mental models for decision-making - Evidence: "I'm trying to help you make a mental mapping and model for how to choose the right place to host your code" #### ⏱️ [03:15](https://youtu.be/yfxDdQo2cyI?t=195) — [H2] Serverless vs VPS Framework - Key idea: Start with serverless unless you have specific server needs - Evidence: "98 plus% of applications can be served totally fine in a serverless deployment solution" #### ⏱️ [04:30](https://youtu.be/yfxDdQo2cyI?t=270) — [H3] AWS Lambda Limitations - Key idea: Lambda has significant setup complexity and concurrency issues - Evidence: "Lambda is not trivial to set up... Concurrency is not viable" #### ⏱️ [06:45](https://youtu.be/yfxDdQo2cyI?t=405) — [H2] Cloudflare's Unique Architecture - Key idea: Cloudflare uses isolates instead of containers for better cold starts and pricing - Evidence: "Instead of handing them a box with a kernel... you're handing them a JS file" #### ⏱️ [09:20](https://youtu.be/yfxDdQo2cyI?t=560) — [H3] Cloudflare Node.js Compatibility Issues - Key idea: Not running true Node.js creates package compatibility problems - Evidence: "Things like sharp and ffmpeg, you're not running anything that is written in a language other than JavaScript" #### ⏱️ [11:30](https://youtu.be/yfxDdQo2cyI?t=690) — [H3] Cloudflare Dashboard Problems - Key idea: Cloudflare's developer experience is severely hampered by poor tooling - Evidence: "The dashboard is absolute garbage... should be deleted and restarted from scratch" #### ⏱️ [13:45](https://youtu.be/yfxDdQo2cyI?t=825) — [H2] Netlify as Solid Alternative - Key idea: Netlify provides reliable Lambda wrapper with good integrations - Evidence: "I've never regretted my use of Netlify in a meaningful way" #### ⏱️ [15:15](https://youtu.be/yfxDdQo2cyI?t=915) — [H1] Vercel as Gold Standard - Key idea: Vercel remains easiest and most consistent deployment experience - Evidence: "Still by far the easiest and most consistent way to deploy most apps" #### ⏱️ [17:30](https://youtu.be/yfxDdQo2cyI?t=1050) — [H3] Vercel Bandwidth Cost Trap - Key idea: CDN bandwidth charges are the primary cause of shocking Vercel bills - Evidence: "Every time I see one of those viral bills... All but one of those instances, it was bandwidth" #### ⏱️ [20:45](https://youtu.be/yfxDdQo2cyI?t=1245) — [H3] Hetzner Reliability Concerns - Key idea: Hetzner has serious account management and reliability issues - Evidence: "They didn't like that I signed up with a Gmail account, so I got auto flagged" #### ⏱️ [23:15](https://youtu.be/yfxDdQo2cyI?t=1395) — [H2] Digital Ocean's Documentation Legacy - Key idea: Digital Ocean built exceptional developer resources beyond their platform - Evidence: "I would not be the dev I am today if it wasn't for the Digital Ocean documentation on how to host Minecraft servers" #### ⏱️ [26:30](https://youtu.be/yfxDdQo2cyI?t=1590) — [H2] Fly.io Innovation and Risk - Key idea: Fly.io offers unique technical capabilities but faces financial uncertainty - Evidence: "One of the most fun platforms I've ever built on. Not confident that they will still be here next year" #### ⏱️ [30:15](https://youtu.be/yfxDdQo2cyI?t=1815) — [H2] Render's Stability - Key idea: Render provides reliable Heroku alternative with solid business model - Evidence: "They make enough revenue that I'm not worried about them disappearing anytime soon" #### ⏱️ [32:45](https://youtu.be/yfxDdQo2cyI?t=1965) — [H1] Railway Excellence - Key idea: Railway combines modern DX with transparent pricing and strong fundamentals - Evidence: "Railway makes me smile every time I use it... They just raised $100 million" #### ⏱️ [37:20](https://youtu.be/yfxDdQo2cyI?t=2240) — [H2] AWS Cost Reality - Key idea: AWS is surprisingly expensive compared to modern alternatives - Evidence: "A 2 gig 1vcpu box with just EBS storage is $22 a month" ## 📚 References - [Vercel Platform](https://vercel.com) - [Railway Cloud](https://railway.app) - [Render Hosting](https://render.com) - [Cloudflare Workers](https://workers.cloudflare.com) ## 🗣️ Paraphrase - Most applications should start with serverless platforms because they handle 98% of use cases without the complexity of managing servers - The top recommended platforms (Railway, Vercel, Render) offer the best combination of developer experience, transparent pricing, and business stability - Hidden costs like bandwidth charges can dramatically impact total cost, making careful platform evaluation crucial for long-term success ## 📰 Newsletter **Platform Selection Made Simple: Your 2026 Deployment Guide** Choosing where to deploy your applications doesn't have to be overwhelming. Start with the serverless-first principle: if you're unsure whether you need a server, you probably don't. **Top Recommendations:** - **Railway**: Modern DX with transparent pricing and $100M funding - **Vercel**: Best GitHub integration, just watch bandwidth costs - **Render**: Reliable Heroku alternative with enterprise backing **Key Takeaway**: Focus on platforms with clear pricing, good developer experience, and strong business fundamentals rather than chasing the cheapest options. Resources: [Railway](https://railway.app), [Vercel](https://vercel.com), [Render](https://render.com) ## ✅ Action Items #### DevRel - Developer advocacy: Create platform comparison workshops for different use cases - Education: Develop cost optimization guides for each recommended platform - Developer experience: Document migration paths between platforms - Developer marketing: Share real-world deployment cost breakdowns - Community management: Moderate platform recommendation discussions #### OSPO - Policy & Governance: Establish platform evaluation criteria for open source projects - License Compliance: Review platform terms for open source compatibility - Security Management: Audit platform security practices and compliance - Software Inventory: Track which projects use which deployment platforms - Developer Support: Provide platform selection consultation - Community Engagement: Fund community infrastructure on recommended platforms - Strategic Alignment: Align platform choices with organizational goals #### Community - Maintainers: Provide deployment platform recommendations in project templates - Contributors: Create getting-started guides for each platform - Sponsors: Negotiate community discounts with recommended platforms - Ecosystem: Coordinate platform evaluations across related projects #### WordPress - Core: Evaluate deployment options for WordPress.org infrastructure - Core Performance: Test performance across different hosting platforms - Community: Create WordCamp deployment workshops - Training: Develop hosting selection curriculum - Marketing: Document WordPress hosting best practices - Support: Build knowledge base for common deployment issues - Design: Create platform comparison visualization tools - Documentation: Update hosting recommendations in official docs - Meta: Evaluate .org infrastructure platform choices - CLI: Add deployment commands for recommended platforms - Hosting: Partner with community-friendly hosting providers - Openverse: Optimize deployment for media-heavy applications #### The WPCC - Programs: Fund community hosting for qualifying projects - Projects: Sponsor migration away from unreliable platforms - Funding: Provide hosting grants for open source WordPress projects #### FAIR - Technical independence: Avoid vendor lock-in through platform standardization - Policies: Establish platform evaluation transparency requirements - Governance artifacts: Document platform selection decision processes ## 🧪 Hypotheses - Serverless platforms will continue consolidating around developer experience leaders - Bandwidth costs will become increasingly important as applications become more media-rich - Platform business model sustainability will become a primary selection criterion - Developer experience quality will increasingly differentiate similar platforms ### 📊 Methodology - Compare total cost of ownership including hidden fees across platforms - Test deployment workflows and developer experience for common use cases - Analyze platform business fundamentals and funding status - Survey developer satisfaction and migration patterns ### ❓ Questions - How will AI-assisted deployment tools change platform selection criteria? - Which platforms will successfully transition from startup funding to sustainable revenue? - How will edge computing adoption impact serverless vs VPS preferences? ### 🔮 Future Research - Long-term cost analysis across different application growth patterns - Developer productivity metrics comparison between platforms - Platform reliability and uptime analysis over extended periods ### 💡 Implications - Practice: Standardize on 2-3 platforms to reduce operational complexity - Policy: Establish clear platform evaluation and migration procedures - Security: Regular platform security posture assessments required - Education: Platform-specific deployment training becomes essential - Funding: Budget for potential platform migration costs and bandwidth scaling ### 🧠 Learning Styles Assessment Reading level estimate: 10th Grade (Flesch-Kincaid) #### 👀 Visual learners - Present: Platform comparison charts, pricing tables, architecture diagrams - Improve: Cost breakdown visualizations, deployment flow diagrams #### 🔊 Aural learners - Present: Video format with detailed explanations and examples - Improve: Audio-only version for commuting, podcast episode format #### 🗣️ Verbal learners - Present: Clear terminology definitions, platform analogies, specific examples - Improve: Glossary of deployment terms, platform comparison narratives #### 🧩 Kinesthetic learners - Present: Step-by-step deployment examples, hands-on platform trials - Improve: Interactive platform selection tool, deployment checklists #### 🧠 Logical learners - Present: Decision trees, cost comparisons, feature matrices - Improve: Platform scoring rubrics, ROI calculations, migration timelines #### 🧑‍🤝‍🧑 Social learners - Present: Community discussions, shared experiences from other developers - Improve: Platform user communities, peer review sessions #### 🧘‍♀️ Solitary learners - Present: Detailed written analysis, self-assessment tools - Improve: Personal deployment strategy worksheets, reflection prompts #### 🌿 Naturalistic learners - Present: Platform ecosystem connections, growth pattern analogies - Improve: Sustainability impact comparisons, environmental considerations ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy, descriptive link text - Improve: Alt text for comparison charts, table headers for pricing data #### Keyboard navigation - Present: Video player keyboard controls, logical tab order - Improve: Skip links for long content sections, keyboard shortcuts #### Contrast and readability - Present: High contrast text, readable font sizes - Improve: Color-blind friendly chart colors, adjustable text sizing #### Text resizing and reflow - Present: Responsive layout at 200% zoom - Improve: Maintain readability of comparison tables at high zoom #### Media and captions - Present: Video with spoken content, visual demonstrations - Improve: Detailed captions, audio descriptions for visual comparisons #### Forms and interactions - Present: Interactive elements for platform comparison - Improve: Clear error messages, accessible form validation #### Standards reference - Follow WCAG 2.2 AA guidelines for all comparison tools and interactive content ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global platform availability considerations, multi-region examples - Improve: International pricing variations, local compliance requirements #### Inclusive language - Present: Clear technical explanations, defined jargon - Improve: Alternative explanations for complex concepts, avoid cultural idioms #### Neurodiversity support - Present: Structured content with clear sections, consistent formatting - Improve: Executive summaries, progressive disclosure of complex information #### Representation - Present: Varied use cases and developer backgrounds - Improve: Diverse example applications, inclusive imagery #### Psychological safety - Present: Respectful platform comparisons, acknowledgment of different needs - Improve: Non-judgmental language about platform choices, supportive tone ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear criteria applied consistently across platforms - Inductive strength: Patterns identified from specific platform experiences - Causal reasoning: Links between platform choices and business outcomes - Analogical strength: Appropriate comparisons between similar platforms #### Fallacies - Ad hominem: Some personal attacks on Hetzner beyond business concerns - Appeal to authority: Heavy reliance on personal experience without broader data - False dilemma: Occasional oversimplification of complex platform tradeoffs #### Tone of voice - Overall tone: Opinionated but informative, with clear bias toward specific platforms backed by experience ### 🛡️ DARVO Analysis - Deny: No significant denials of legitimate platform concerns - Attack: Some harsh criticism of Hetzner and Cloudflare that may exceed balanced assessment - Reverse victim/offender: No victim/offender role reversals identified - Emotional c --- ## Full Transcript [00:00] Today's video is going to be a bit [00:01] different because I wasn't actually [00:02] filming this video when I filmed most of [00:04] this video. I know that sounds crazy, [00:06] but just hear me out for a sec. I was [00:07] just filming a video about the death of [00:09] Heroku. You might have even seen it [00:11] already. And that video ended up with a [00:12] long tangent about various other [00:14] alternatives that you might consider [00:16] moving to. Everything from AWS to [00:18] Verscell, Railway, Netlefi, Render, [00:21] Cloudflare, Digital Ocean, Hner, Flight, [00:23] and more. I wanted to do my best to [00:25] break all of these options down and [00:27] share how I think about them and how I [00:29] choose where I deploy my applications. [00:31] While I have been sponsored by many of [00:33] these companies in the past, none of [00:34] them are sponsoring this video. The [00:36] point of this was to give you my honest [00:38] take on how I choose where I deploy my [00:40] services. It can feel a little [00:42] overwhelming to choose and a lot of the [00:44] advice I see around the internet feels [00:46] like it's coming a little bit too much [00:48] out of the perspective of the user and [00:50] the specific thing they are working on [00:52] in that moment where all of these [00:54] platforms, okay, most of these platforms [00:56] have real benefits that are worth [00:57] considering. There are at least three [00:59] options on each side here that are worth [01:02] thinking about and evaluating before [01:04] making a decision. And this video isn't [01:06] just like this one's good and this one's [01:08] bad. I'm trying to help you make a [01:09] mental mapping and model for how to [01:11] choose the right place to host your [01:13] code. And in a world where we're [01:14] deploying more and more services, making [01:16] all these micro apps, and vibe coding [01:18] all sorts of stuff, no one's helping you [01:20] figure out where to put it. And if I [01:22] keep seeing these crazy versell bills or [01:24] people getting stuck trying to deploy on [01:26] AWS, I'm going to go mad. I really want [01:28] to help you guys understand how I pick [01:30] solutions. And it's not based on who's [01:32] paying me. None of these companies are [01:34] paying me today. The only one who is is [01:36] today's sponsor. I have a confession to [01:37] make. I've stopped using GitHub for CI [01:40] because today's sponsor, Blacksmith, has [01:41] made my CI so much better. Actions just [01:44] aren't reliable, and I've had so many [01:46] problems with them. And they all [01:47] vanished as soon as I set up Blacksmith [01:48] for all of our repos. And yes, I mean [01:50] all of them. Looks like we even have [01:51] jobs running right now. Honestly, all of [01:53] the observability stuff would be worth [01:54] it by itself. Actually seeing what [01:56] failed and why and having a log search [01:58] that like works. If you've ever had to [02:00] debug weird actions, you know how [02:02] absurdly useful this is by itself. It is [02:04] not just for individual projects. You [02:06] can scan all of your projects as well, [02:08] which is huge. But the real key is the [02:10] fastest part because they really are the [02:12] fastest. The secret to how they're so [02:13] fast isn't really that secret. They're [02:15] using better hardware with gaming CPUs [02:17] as well as NVME drives that store all of [02:19] your layers for things like Docker, [02:20] which allows the restoration process to [02:22] be instantaneous instead of taking [02:24] forever. I just moved some actions for a [02:26] Rust project I'm working on, and they [02:27] went from 5 minutes to under 30 seconds. [02:29] We've seen similar speedups across all [02:31] of the projects that we're working on. [02:32] Other companies like Ashb doubled their [02:34] deployment speeds while also cutting [02:35] their spend by 75%. Because yes, [02:38] Blacksmith's cheaper, too. Don't believe [02:40] me? Try it yourself. It's free to get [02:42] started and it's one line of code [02:43] changed. Yes, really. You swap the [02:45] action. Once you're set up, it's good to [02:47] go. Stop wasting your time and speed up [02:48] your builds at soyv.link/blacksmith. [02:50] I'll break this into servers and [02:52] serverless. You know, we'll call it [02:53] VPS's and serverless. There's a lot of [02:56] good options for both. In the serverless [02:59] side, obviously Verscell is still [03:01] inarguably king. The balance of DX and [03:03] capability of the platform is pretty [03:05] hard to beat. Nellifi is not a bad [03:07] option, especially with their recent [03:09] embrace of vibe coding and supporting [03:10] all of the platforms that build all the [03:12] fancy vioding tools. Scales great. I [03:14] love the CEO. Really good. Has it [03:16] negatives. We'll get there. And then we [03:17] have Cloudflare. A lot of things to say [03:19] about that. On the VPS side, we have a [03:21] ton of options. Obviously, we can go AWS [03:24] with EC2 or EKS. Lots of options there. [03:28] Railway, which I've already talked [03:29] about. You have render fly.io. Yeah, [03:32] digital ocean. Another crazy throwback. [03:35] Man, I have digital ocean. I have a long [03:37] ass history. Oh, yeah. Hner, the [03:39] classic. That's the one I was [03:40] forgetting. Obviously, there's other [03:42] traditional clouds like GCP, Azure. The [03:45] reality is that if either of these are [03:46] the right solution to your problem, you [03:48] already know that and you're not here [03:49] for me to tell you about different [03:50] options. There's also OVH. None of the [03:53] rest are things I care about enough to [03:55] put in the list. I think this is a good [03:56] enough list of the VPS's. I'm going to [03:58] start by diving into the serverless list [04:00] here. If you don't know which of these [04:02] you fit under, you should almost [04:04] certainly start with the serverless [04:05] options and if they have issues because [04:08] you actually do end up meeting a server, [04:09] you'll figure that out pretty fast and [04:11] then you'll move over accordingly. But [04:13] generally speaking, 98 plus% of [04:15] applications can be served totally fine [04:17] in a serverless deployment solution. I [04:19] would lean in that direction. So that's [04:20] being a fair point that AWS Lambda [04:23] should also be in here. You're not [04:25] wrong, but we're not going to be talking [04:26] about that one too much. Let's break [04:28] down all these options and how I pick [04:30] between them. I honestly think this will [04:32] be easier if we go backwards. So, let's [04:34] start with AWS Lambda. Lambda is not [04:37] trivial to set up. There are lots of [04:39] tools to help like SST, Palumi, [04:41] Terraform, things like that. It still [04:43] sucks. Concurrency is not viable. They [04:46] are starting to introduce their concept [04:48] of doing concurrent Lambda stuff. [04:49] They're not there yet. I don't know [04:50] anyone who's actually using it or [04:52] relying on it. Then they have like [04:53] amplify which is a total joke. Yeah. CDN [04:57] gateway is your problem. Git push [05:00] pipeline GHF costs are fine but [05:04] concurrency sucks. Yeah. It's hard to [05:07] recommend Lambda to most people. At [05:09] least it's Node though or anything else. [05:11] If you can put in a Docker image, you [05:12] can put it on Lambda. But a lot of [05:14] technologies that people like tend to be [05:16] slow to spin up. So don't think you can [05:19] just rewrite your Lambda in Rust and [05:21] it's magically super fast. Sometimes [05:23] those things take a bit to boot, [05:24] especially if your wait time isn't on [05:26] the startup of your code. It's actually [05:27] on the connection to your database. Good [05:29] luck. Have fun. There's also a lot of [05:31] other little things like streaming with [05:32] super broken Lambda. I think it might be [05:34] fixed now. I'm not sure, but if you're [05:35] using a server component style framework [05:37] that does HTTP streaming like you know, [05:38] Nex.js, not fun. And next we have [05:42] everyone's favorite CloudFlare. First [05:44] thing I want to say is that they have [05:45] one of a kind infra. And that one of a [05:47] kind infra allows them to be [05:49] significantly cheaper than almost [05:50] anything else because Cloudflare isn't [05:52] using traditional servers or Docker [05:55] images. You can't send a Docker image to [05:57] Cloudflare and run it. Well, you kind of [05:59] can now, but their whole like Docker [06:01] image server thing is a different [06:02] product and it sucks. I don't anyone [06:03] using it. It's super overpriced and [06:04] slow. Cloudflare's strength is you give [06:06] them a JavaScript file and they run it [06:08] on their edge network that has a [06:10] different layer of abstraction. Instead [06:12] of handing them a box with a kernel in [06:14] it and expecting them to run it for you, [06:15] you're handing them a JS file and three [06:18] layers above the kernel in their custom [06:19] version of V8 called workerd, they run [06:22] your code safely in an isolate that [06:24] doesn't have to spin up a whole server [06:26] the way that things like Lambda do. That [06:27] means that cold starts are near zero. It [06:29] means that their pricing model is [06:30] fundamentally different because they [06:32] only charge on CPU time. Other platforms [06:34] charge wall clock time because the [06:36] server's up. It doesn't matter how [06:37] people are using it. It costs them [06:39] money, it costs you money, too. With [06:41] Cloudflare, if your request isn't doing [06:43] anything, like it's idling, waiting for [06:45] more data to come in, the compute on [06:47] that box can be used for someone else's [06:49] request because lots of people are [06:51] running their code at the same time on [06:52] the same box. On Verscell, every [06:54] developer's deployment has its own [06:56] kernel. On Cloudflare, every single [06:58] deployment is just a JavaScript file [07:00] running in the same VM. It also changes [07:01] their performance profile meaningly. [07:03] Check out the Verscell versus Cloudflare [07:04] video if you want more info on that. [07:05] They've made improvements since, but [07:07] it's still not as fast as dedicated box [07:09] can be. But there's a much bigger catch. [07:11] Not Node. Every time I use Cloudflare, I [07:14] run into something because of this. It's [07:16] not running Node.js. It's running their [07:18] JavaScript engine. And because of that, [07:20] a lot of things don't work. Things like [07:23] reading and writing files, things like [07:25] many of the methods you use to connect [07:27] to databases, things like any package [07:30] that runs any native code, you know, [07:32] like image optimizers, PDF parsing, all [07:35] the fun things we like to do in our [07:37] servers with our node apps. There's a [07:39] lot of issues when you can't use node. [07:41] They've done their best to patch in [07:43] support for a lot of node stuff. None of [07:46] the things I just mentioned have been [07:47] fixed. All of those are still problems, [07:49] but most packages have shims around the [07:50] node functions now built in where they [07:53] can mostly work. Things like crypto were [07:55] entirely broken and now mostly work. The [07:57] compat layers fine, but you're almost [08:00] certainly going to run into some issues. [08:01] Like one of the biggest ones I have is [08:03] stuff like sharp and ffmpeg. you're not [08:05] running anything that is written in a [08:06] language other than JavaScript in [08:08] Cloudflare. And anyone saying otherwise, [08:10] like, oh, you can just wom your stuff [08:13] has not tried it seriously. I have been [08:15] to hell and back for many projects [08:17] trying to get Cloudflare to let me do [08:18] something that involves any code that [08:20] isn't in JavaScript and every single [08:22] time I gave up and moved to one of the [08:23] other options. Speaking of other [08:25] options, Netlefi. Nellifi is another [08:27] Lambda wrapper, but they include all the [08:29] other fun things like the CDN that make [08:31] the platform so nice. Everything from [08:33] here down effectively has those pieces. [08:36] Really good GitHub integrations. [08:38] Honestly, really good integrations in [08:39] general. They have an awesome team. They [08:41] support the hell out of open source. [08:43] They're pretty good. I've never [08:44] regretted my use of Netlefi in a [08:46] meaningful way. They've been a sponsor [08:47] in the past. I wouldn't be surprised if [08:48] they are again in the future. Netlefi is [08:50] solid platform. They handle CDN and [08:54] distribution stuff, but they don't have [08:56] everything. The biggest thing I miss [08:58] when I use Netlfi is concurrency because [09:01] again the concurrency model for a lot of [09:03] these things including AWS Lambda is [09:05] each request gets its own instance and [09:08] for the modern way that things work that [09:10] is not pleasant. Their solution for this [09:12] is some really cool background jobs and [09:15] Q type stuff. The work they have done [09:17] for their queuing things is actually [09:19] really really cool. The bit I played [09:20] with it for was awesome. They were way [09:22] ahead of Versel with the workspace [09:24] thing. They had it figured out early and [09:26] it was surprisingly cheap. I should also [09:27] mention for the Cloudflare stuff before [09:29] I forget, GitHub integration, GHF. [09:32] Getting your Cloudflare stuff integrated [09:33] with modern tools is still your problem, [09:36] not theirs. The dashboard is absolute [09:38] garbage. I I actually think that the [09:40] entire dashboard codebase should be [09:43] deleted and restarted from scratch. [09:45] There is no recovery at this point. [09:46] They've had multiple massive global [09:48] outages because of bad code for fetching [09:51] data in the dashboard. It's pretty [09:53] pathetic. Addy just jumped in saying [09:55] Cloudflare pages is native GitHub [09:56] integration. Awesome. Cloudflare pages [09:58] is also dead. They are merging it with [10:01] Cloudflare workers now and they've done [10:03] a terrible job documenting those changes [10:05] and I never know where I'm going when [10:07] I'm trying to deploy on Cloudflare [10:08] anymore. I had so many problems the last [10:10] time I tried to deploy on Cloudflare [10:11] that I sent to the team. The poor exec [10:13] who was in the room with me when I did [10:14] this wrote over seven pages of notes at [10:17] a 10-point single spaced font that she [10:19] then presented to the entire org and got [10:21] like half or so of the things fixed. [10:23] They are trying. Cloudflare does care a [10:25] lot, but the experience is just so far [10:28] behind any of the competition that's at [10:30] all more modern. Just go try to deploy a [10:33] random V react app on Cloudflare and on [10:36] Versel and then make a change and see [10:38] how hard it is to deploy on those two [10:39] things. It's just not pleasant. But what [10:42] you're getting for that cost of your [10:44] sanity is way cheaper overall. There are [10:48] issues with the cost side though because [10:50] they're not very transparent about what [10:52] free things stay free. They don't charge [10:54] for egress in a bunch of cases which is [10:56] huge because it means if you're doing a [10:57] lot of data transfer it is cheap or free [11:00] but at a certain point they might [11:02] strongarm you into the enterprise plans [11:04] where those things suddenly do cost [11:05] money. So if it's free on the free tier [11:07] or free on the base tier that does not [11:09] guarantee it stays free in the [11:10] enterprise tiers. So know that cuz it's [11:12] very important. One last really great [11:14] thing they did though they hired Dylan. [11:15] If you're not familiar, Dylan Moy is one [11:17] of the like wizard Typescript devs [11:19] powering all sorts of tools in the [11:21] background. One of the people that's [11:22] really pushed Effectts to where it is [11:24] today. Fellow JJ nerd, great developer [11:27] overall. Love Dylan to death. He was at [11:29] Versell and cared a lot about DX there. [11:31] He's now at Cloudflare and he's pushing [11:32] the limits of DX there as well. Trying [11:34] to fix a ton of stuff. In his first [11:36] week, he filed like 20 PRs to the [11:38] Wrangler CLI and all these other random [11:40] things. There's a good chance that Dylan [11:42] will be able to fix a handful of the [11:43] things in this list, but right now, [11:44] Cloudflare has the second worst DX [11:47] compared to AWS. In many ways, I would [11:49] argue it's worse than AWS because it [11:51] changes all the time and is never well [11:53] documented and nothing ever makes sense. [11:55] It's actually so unclear what you can [11:57] and can't do on Cloudflare because the [11:59] docs are just wrong and lie a lot. It's [12:01] it's rough. And now for the exact [12:03] opposite experience, Verscell. I have my [12:06] issues with Verscell. Everyone does. [12:08] Watch my breaking up with Versell video [12:10] if you want to see some of them. There's [12:11] a lot of them, but they are still by far [12:13] the easiest and most consistent way to [12:15] deploy most apps. Basically, everything [12:18] I have shipped to the web over the last [12:20] few years has been on Versell at the [12:22] very least for the web app for it cuz [12:24] it's just a really easy way to do that. [12:25] The GitHub integration is great. The [12:27] free tier is great. The billing model [12:28] makes sense. The integrations with [12:30] everything are awesome. Honestly, I can [12:32] just copy this part as well as this [12:35] part. Obviously, it's the best place for [12:37] Nex.js JS regardless of how you feel [12:38] about next even I'm coming around to not [12:40] liking next too much nowadays obviously [12:43] they handle the CDN distribution stuff [12:45] and the parts where we start to really [12:47] differ from the competition fluid [12:49] compute this is the thing I talked about [12:50] before it's their attempt to do similar [12:52] pricing to what Cloudflare does with the [12:55] CPU time pricing it has helped a ton [12:57] they also consistently introduce cool [12:59] primitives to the infrastructure that [13:00] take advantage of these things like the [13:02] workflows stuff I know you guys don't [13:04] love the whole syntax of direct [13:06] directives with use workflow and [13:08] whatnot, but it is really cool what it [13:10] can do. It's a good way to get started [13:12] with that type of building if you want [13:14] more reliable services. It is what it [13:16] is. There are negatives though. Cost is [13:18] still an issue, not just CPU cost. I [13:21] would actually argue for most apps, the [13:23] cost difference between Versel and [13:25] Lambda is in favor of Versell for the [13:28] compute side because of the concurrency [13:30] stuff in particular. That just knocks [13:32] costs down a shitload. But they do [13:34] things with the costs that still aren't [13:36] great. Things like the $20 per month [13:38] seat pricing. Very annoying. Every time [13:40] I have to add a new dev to the team, I'm [13:42] just increasing my Verscell bill. Don't [13:44] love that. But the biggest cost when [13:46] you're shipping real software is almost [13:48] never going to be the compute or the [13:50] seat pricing on Versel. Bandwidth. Every [13:53] time I see one of those viral bills [13:55] where it's like, "Oh my god, Verscell [13:56] cost me $5,000." All but one of those [13:59] instances, it was bandwidth. Because [14:01] Versell has a very aggressively [14:03] positioned CDN that has the goal of [14:05] making everything as fast as possible. [14:07] All of the code that Verscell ships for [14:09] you, the things that go to the users [14:11] like your HTML pages, your JS bundles, [14:13] your SVGs, all the things that are [14:16] coming out of your codebase that are [14:17] going to the user, those are all on [14:19] Versel's CDN. It is obviously meant for [14:21] things that are small and need to be [14:23] loaded quick, like you know, JavaScript [14:25] files that power your site. But if [14:26] you're filling up your public folder in [14:28] your project with a ton of big assets [14:30] like 50 megabyte video files or 10 [14:32] megabyte PGs or 5 to 10 megabyte MP3s, [14:36] that's going to cost a lot. It's almost [14:38] like you're trying to use a race car to [14:39] pick up groceries. Not only is it going [14:41] to fit fewer groceries, it's going to [14:43] use more gas and probably cost you more [14:45] maintenance. It is not the right [14:47] solution for any static asset that is [14:50] bigger than like 400 kilobytes. They do [14:52] offer their own file storage solution [14:54] called blob that is built on top of R2, [14:56] funny enough, the Cloudflare product. I [14:58] don't know how hard they're focused on [15:00] it now. It doesn't really seem like a [15:01] thing they care a lot about. Thankfully, [15:02] you can use upload thing, a weird file [15:05] upload service some random YouTuber [15:06] made. Don't think about that part too [15:08] much, but uh it's a lot cheaper. Doesn't [15:10] charge for egress. Worth considering. [15:12] So, that's why I default to Verscell. As [15:14] long as you're careful about the [15:16] bandwidth and where you're putting it, [15:17] it ends up being really good. The GitHub [15:18] integrations are best in class. The CLI [15:20] is really good. It's easy to set up. It [15:22] works with everything. It's real node, [15:23] so you can do anything you can do in [15:24] Node.js. It's pretty good. Generally [15:27] speaking, if it doesn't work on Versell, [15:28] it's probably because it's a bad [15:29] workload for serverless in general. It [15:32] is very rare that I find it worthwhile [15:34] to move off of Versel to another [15:36] serverless provider, unless it is some [15:38] crazy weird compute thing that [15:40] Cloudflare happens to be cheaper for. [15:42] But even that's getting rarer now with [15:44] the fluid compute pricing. Cool. So, [15:46] let's say you're one of those people [15:48] that just cannot use serverless. There [15:51] are a lot of people that that is the [15:52] case for and there are even more people [15:54] that that isn't the case for but [15:55] occasionally have a project that [15:57] benefits from traditional servers. Let's [15:59] look at our options for that. Let's [16:01] start with the easy ones to make fun of [16:04] Petner and OVH. Benefits really cheap. [16:07] People on Twitter will think you're [16:08] cool. Negatives, uh, your account can [16:11] get cancelled at any time, especially [16:14] with Hster. I've even experienced this. [16:16] They didn't like that I signed up with a [16:17] Gmail account, so I got auto flagged and [16:20] my account couldn't deploy for a long [16:22] ass time. It was bad. And I've seen that [16:24] story so many times. I've even seen [16:26] people's production environments getting [16:27] taken down because some random policy [16:28] change resulted in their account not [16:30] having some checkbox hit. They are known [16:33] for banning. They are known for [16:34] flagging. A lot of people have had a lot [16:36] of problems. Immediately, I get [ __ ] for [16:38] talking [ __ ] on Hesser, but I don't [16:40] care. I've exclusively had bad [16:41] experiences with Hner, and I need y'all [16:42] to know that. OVH is some amount better, [16:45] but honestly they're also slightly more [16:46] expensive, so I rarely find it is worth [16:48] it. The product offering is also [16:50] lacking. Like no integrations with [16:52] anything. If you're using Hatner, you're [16:55] managing your deployment pipelines. [16:56] You're managing your methods for [16:58] allocation. You're managing your [17:00] hierarchy for like what servers are [17:01] being routed to and from your gateways, [17:03] your CDNs, everything. They're not doing [17:05] [ __ ] for you. They're giving you a VPS [17:07] in a box that they own somewhere random. [17:09] Also of note, uh locations kind of suck. [17:11] The best prices are for the EU servers, [17:13] but even the EU servers aren't [17:15] coll-located with other important [17:17] things. Like if you're using, I don't [17:19] know, planet scale for your database, [17:20] the likelihood that the planet scale [17:22] database and the heter database are on [17:24] the same network is basically zero, [17:27] which means you're adding a shitload of [17:29] latency and making your service [17:30] significantly slower and worse so that [17:32] you can look cool on Twitter for paying [17:34] five bucks a month instead of six. It's [17:36] just not worth it. I I don't know any [17:37] serious people who are building on top [17:39] of Hetner. I just don't. It's all [17:41] hobbyists. And that's fine if you want [17:42] to just be a hobbyist and really [17:44] microoptimize your costs. I don't [17:47] believe that you're real. I just don't. [17:49] Not a hatner fan. I'm sure my comment [17:51] section is going to be wonderful now [17:53] that I've said that. Next, we'll talk [17:55] about Digital Ocean. This is one I have [17:58] a ton of experience with. First benefit [18:00] is the docs. Best in class. I in chat, [18:04] tell me if you're old enough to have [18:06] been there with me. Ones in the chat. If [18:08] you've also relied on the docs for [18:10] Digital Ocean, for deploying Minecraft [18:13] servers places other than Digital Ocean. [18:15] I know that's been the case for me. I [18:16] would not be the dev I am today if it [18:18] wasn't for the Digital Ocean [18:20] documentation on how to host Minecraft [18:22] servers. Look at that chat. A lot of us [18:24] have been there. Crazy throwback, but [18:26] man, the amount of quality documentation [18:28] that they have had forever now is just [18:31] unbelievable. Like to this day, I'll [18:33] Google search some weird thing I want to [18:35] do with SSH or GNU screen or some thing [18:37] I want to deploy. There's a 50% chance [18:39] that Digital Ocean is one of the first [18:41] results and not even how to do this on [18:43] Digital Ocean. It's just how to do this. [18:45] And if you choose to use Digital Ocean, [18:47] you can. They really took that angle [18:49] seriously of just being a good resource [18:50] for developers. They have since laid off [18:52] a lot of the staff that wrote those [18:53] docs, but god damn were they useful for [18:55] a long, long ass time, even like [18:58] pre-stack overflow days. Other benefits [19:00] of Digital Ocean, they've been around [19:02] forever, so they're probably not going [19:03] anywhere. They have good integrations, [19:05] not great, but good integrations with [19:07] things like GitHub. I'll call it decent [19:09] integrations and a lot of companies that [19:12] we use things from here are using them [19:14] from Bright Data to FAL to Character AI [19:16] and more. Like they're they're a real [19:17] legit company that's being used by a lot [19:19] of real legit products unlike some of [19:21] the other options here. We need to take [19:22] a look at the pricing though because [19:23] it's not cheap. They're immediately [19:25] starting with their GPU boxes, which is [19:28] cool that they offer those, but the [19:30] compute less great. They do still have a [19:32] free tier, but droplets, oh, they're now [19:34] per second pricing. Their base here at [19:37] 512 meg, 500 gigs of transfer, 10 gig [19:40] drive is four bucks a month. 1 gig is up [19:43] to six. And just for comparison sake, [19:46] we'll look at Hner's pricing. They got [19:48] boxes with 4 gigs of RAM and 40 gig SSDs [19:51] and up to 20 terabytes of traffic for [19:53] four bucks a month. This is why people [19:55] choose Hner. It is also worth noting [19:57] that it's in Germany or Finland. And I [20:00] don't think the US locations are even [20:02] visible in the pricing charts. Or is it [20:04] regular performance? That's okay, cool. [20:06] Regular performance. A different tab [20:08] than the cost optimized ones. And those [20:10] ones have US locations. And now we're up [20:12] to six bucks for the 2 gig 40 gig plan. [20:14] That's a lot closer to what we were [20:16] seeing over here. So it as crazy as it [20:20] seems, do you understand how hard Hner [20:22] works to make the price look incredible [20:26] even though there are catches? Like [20:28] again, we have to hit this button to get [20:30] real locations and immediately the price [20:32] skyrockets. Turns out that the two vCPU [20:35] 4 gig boxes in Germany in regular [20:38] performance mode, not cost optimized [20:40] mode, is more expensive than Digital [20:43] Ocean. And if you want a dedicated box [20:45] so that you never have to worry about [20:47] performance degrading, you're now at 14 [20:49] bucks a month minimum for again relative [20:51] small. Okay, it's 8 gigs of RAM. It's a [20:52] little bit better, but 28 bucks for 16 [20:54] gigs a month, not great. Regardless, [20:57] pricing is reasonable across these [20:59] options so far. We have not gone into [21:00] the things that are massively [21:01] overpriced. Okay, admittedly, 2 gigs of [21:03] RAM and one vCPU for 12 bucks is a [21:06] little expensive. Digital Ocean is not [21:08] the cheap option. It never was. If [21:10] you're optimizing on that level, it's [21:12] hard for me to take the work you're [21:13] doing seriously. Like a $2 to5 a month [21:16] difference across servers is not [21:17] something I care about because the time [21:19] it takes to build those things is a lot [21:20] more. Hell, the inference I use to build [21:22] those things is a lot more. I'm paying [21:23] 200 bucks a month for Claude and for [21:25] Codeex right now. Five bucks a month is [21:26] whatever. So, what are the negatives? [21:29] How do I put this? Digital Ocean feels a [21:31] little lost right now. They don't really [21:33] know what their core offering is. You [21:35] can even tell from the homepage. The [21:37] inference cloud built for scale. What? [21:40] That's not what I've you I don't know [21:41] anyone using Digital Ocean for inference [21:43] right now. I've never met a person who [21:45] does that. Oh, look at that. They have [21:46] an open claw shout out on the homepage [21:48] now. They are leaning so hard into [21:50] trying to find new customers, which [21:52] suggests, this is the scary part, they [21:55] may be circling the drain. Of the [21:58] options I have in this list, they are in [22:00] the top section of most likely to have [22:03] the same problem that we're talking [22:04] about here right now. So yeah, if your [22:06] goal is to not have to deal with this [22:08] type of migration because of the Heroku [22:10] death, I can't guarantee with Digital [22:12] Ocean that you won't have to experience [22:13] that again. So know that going in. [22:15] Definitely feels a tad dated and it [22:17] feels like the compute isn't their focus [22:19] anymore. They really seem to be leaning [22:20] into the inference side, which good for [22:22] them, but there's way more competition [22:24] there, and I'm not confident that they [22:26] can have a meaningful impact. So what do [22:28] we have next? We covered these ones. [22:30] Let's hop into Fly.io next. Flyio is [22:32] dope. They were a sponsor in the past. I [22:34] hope they might be in the future, but [22:36] they did recently have to do layoffs and [22:37] I chose to cut them off as a sponsor at [22:39] that point because I felt really bad [22:40] taking money from a company that just [22:42] laid off a bunch of the staff that I was [22:43] working with. Really good stuff overall [22:45] and they are also a huge member of like [22:47] the elixir community which is obviously [22:48] near and dear to my heart. So benefits [22:51] elixir native which I absolutely love [22:53] worldclass DX for deploying servers. [22:56] They have some of the best DX in the [22:57] world. things like the way it integrates [22:59] with GitHub, how you manage things in [23:00] the dashboard, the clarity in what's [23:02] going on where, the tools for linking [23:04] different things together, preview [23:05] environments, sleeping servers, all of [23:07] those types of things. Great. They're [23:09] also huge OSS supporters. They help [23:12] sponsor everything from like the Elixir [23:14] ecosystem and Gleam, Rails, and many [23:16] other things I'm almost certainly going [23:18] to forget if I try to list them off. [23:19] They are just a good player in the [23:21] space, more so than anyone else we've [23:23] talked about so far. I would argue they [23:25] are actively meaningfully contributing [23:27] to the development of important open- [23:29] source technologies to the point where [23:31] it is hurting the business. Okay, people [23:33] are saying they might not sponsor Gleam. [23:37] Maybe they're not sponsoring Gleam [23:38] anymore. I'm pretty sure they did in the [23:40] past, but they are not necessarily doing [23:42] great financially. Again, layoffs and I [23:45] haven't heard anything about them [23:45] raising anytime soon, which means they [23:47] probably haven't. They also have their [23:49] sprite stuff, which I've heard really [23:50] good things about. It's meant to be VMs [23:53] and sandboxes that you can safely run [23:55] agents in that have their own primitives [23:57] that will let them be powerful. And [23:59] there's a bunch of other random things [24:00] that they've built that are just way [24:02] cooler than what you can do on other [24:04] clouds. I did a video a while back about [24:07] Flame, which is an alternative way of [24:09] doing serverless where you are [24:10] encapsulating processes in your codebase [24:13] to spin them up on different servers for [24:15] specific needs. Like if you want to [24:16] sometimes have a GPU for doing, I don't [24:18] know, ffmpeg stuff, but you usually [24:20] don't need it. Having your stuff always [24:22] run on the GPU box would be way too [24:26] expensive. The GPU is not being used. [24:27] But if you could have one function in [24:28] your codebase that runs on the GPU box [24:30] and spins it up and handles it, then [24:32] awesome. In this example, I'm sorry if [24:34] you're not familiar with Elixir syntax, [24:35] my beloved. You take this process that [24:38] is defined here for generating [24:39] thumbnails, which runs in FFmpeg, which [24:41] could lock up the main server or just [24:44] not be performed if it doesn't have a [24:45] GPU. You can wrap it with a flame call, [24:48] exact same stub function here, and it [24:50] will return the result as though you [24:51] just called this on the same box. It's [24:54] so cool. It's just so far ahead of [24:57] anything else I've seen for this type of [24:59] stuff. But we need to be realistic. The [25:01] negatives, the database reliability just [25:04] isn't there. Even when I was doing my [25:06] tutorials and work with them, I had my [25:07] database just die and fail multiple [25:10] times throughout. I learned to just not [25:12] trust the database, as many other Fly [25:13] customers have. They often move their [25:15] databases off of fly to their own other [25:17] alternative services like you know [25:19] planet scale but during dev it's so [25:21] convenient like the way that setting [25:22] things up on fly is so nice it hurts but [25:25] reality is that the database stuff isn't [25:26] there and in general reliability just [25:28] isn't quite where we need it to be. They [25:30] had a huge outage recently. They likely [25:31] will again in the future. They have [25:33] built a lot of their own things and a [25:35] lot of those things are really really [25:36] cool. It's why they can do all this cool [25:38] stuff but it also means they're not as [25:40] tried by the industry and as a result [25:42] they're not as reliable. Also note with [25:43] the DB thing not managed. They don't do [25:46] managed databases. They just give you an [25:48] image that is running Postgress. [25:51] Apparently they now do have managed [25:52] databases. I did not know that. That's [25:54] good to hear, but uh the last time I [25:56] tried it, they didn't. That is a relief. [25:58] I'm still going to say the reliability [25:59] isn't good, but the fact they have [26:00] managed DB is a cool change. And I would [26:02] also argue that within these options, [26:05] Fly might be the highest risk of death. [26:08] I would put them slightly higher than [26:10] Digital Ocean in terms of this company [26:12] might run out of money and die. I just [26:14] have not seen a lot of big customers or [26:17] revenue numbers or investments or any of [26:19] the things that would make me confident [26:20] Fly will still be here at the end of the [26:22] year or even early next year. Even when [26:23] I was working with them, the rate at [26:25] which the people I was talking to [26:27] suddenly weren't at the company anymore [26:29] was a bit terrifying. I even went to [26:31] Elixir in 2024 and was sitting at a [26:33] table with a bunch of Elixir nerds, [26:34] including a few that worked at Fly, and [26:36] watched as they checked their phones and [26:37] got laid off. That does not inspire [26:39] confidence. They also deprecate things. [26:41] Not a lot, but enough to be concerned. [26:43] Somebody in chat just mentioned that [26:45] they used to have a managed DB Superbase [26:46] integration, but that got discontinued. [26:48] Not the thing I would bet my whole [26:50] business on right now, personally. One [26:51] of the most fun platforms I've ever [26:53] built on. Not confident that they will [26:55] still be here next year. Take that as [26:57] you will. And next we have Render, who [27:00] has this big migrate from Heroku with [27:02] near zero downtime banner on top. They [27:04] know exactly what they're doing. Render [27:06] is used by a ton of big companies. Their [27:09] revenue is really solid. They've had no [27:10] issues raising money. They understand [27:12] modern tech and PHP. Even the founder of [27:15] Hashi Corp has had nice things to say [27:17] about Render. Mitchell's a legend. Cool [27:19] to see. They have a decent free tier. [27:20] You have to immediately bump to their [27:22] monthly tier if you want to do more, [27:24] though. You don't have like boxes you're [27:26] renting the same way, but they're pretty [27:27] generous overall. Relatively modern, [27:29] supports everything, generous free tier, [27:32] likely staying around. They make enough [27:34] revenue that I'm not worried about them [27:35] disappearing anytime soon. Negatives, [27:37] you pay a sub instead of server pricing. [27:42] A lot of that pricing is hidden under [27:43] the enterprise custom tier. They charge [27:46] a separate monthly fee for setting up [27:48] cron jobs. That's kind of funny. Oh, [27:50] look at that. Their GitHub integration [27:52] is still in a very good state. Last time [27:54] I used it, it was pretty good. So, [27:54] that's good to hear. I'll put that in [27:56] here. Good GitHub integration plus [27:58] preview environments, which is not [28:00] guaranteed across these different [28:01] providers. Apparently, the egress is [28:03] super expensive as well. Definitely [28:06] worth noting. Good call out chat. The [28:07] $20 tier comes with 500 gigs of [28:09] bandwidth. 15 bucks per additional 100 [28:11] gigs. Inbound bandwidth is free. Okay, [28:13] that's cool. So, uploading to it is [28:14] free. Sending data from it costs money. [28:16] That's actually a really nice call out. [28:18] Good [ __ ] I would never fault anyone [28:20] for going with render. Seems like a [28:21] really good option. Honestly, like one [28:22] of the most reliable out of all of [28:24] these. Like I I would say like other [28:25] than AWS, least flight risk, too. But [28:28] now we need to talk about Railway. [28:30] Obviously more than at any point in here [28:32] account for bias here. Jake and I have a [28:34] long history. I was almost hired as [28:36] engineer number four at Railway all the [28:38] way back in 2021. I've watched this [28:40] company's ups and downs. I've used them [28:42] for that entire 5-year window. I love [28:45] Railway to death. I have my issues with [28:46] them, but for the most part, it's a [28:48] great platform. It's a phenomenal team [28:50] and I'm very excited for them and all [28:51] the success that they've been having. [28:52] Benefits truly modern. It's just you'll [28:56] feel the difference when you use it. It [28:58] just works great with everything. The [29:00] CLI is awesome. The docs are awesome. [29:01] The GitHub integration is great. It just [29:03] behaves. It also is one of the best [29:05] dashboards for actually seeing what's [29:07] going on and how parts are linked. You [29:09] can clearly see the different services, [29:10] how they're linked to each other. The [29:12] domain setup, all of that really good. [29:14] The observability is awesome, too. I [29:15] haven't even bothered setting it up yet [29:17] cuz this project hasn't needed it. The [29:18] way they handle different environments [29:19] is great. You can set up preview [29:21] environments, things like that [29:22] relatively well. It does not, as far as [29:23] I know, have good automatic preview [29:25] environment creation when you do PRs and [29:27] things like that. It might be able to be [29:28] set up, but it's good. I honestly really [29:31] like the way Addi put it here. Railway [29:32] makes me smile every time I use it. The [29:35] pricing is relatively transparent and [29:36] clear. They drop hard numbers for what [29:38] each thing costs. There's a little [29:40] confusion around various different [29:42] things like the relationship between [29:44] like how these parts are measured. It's [29:45] sometimes confusing to figure out what [29:47] usage you're actually going to get. And [29:49] then there are interesting things that [29:51] are free that I'm not confident are [29:53] going to stay free. So like in the [29:55] benefits section, egress from their [29:58] object store is free. But then in the [30:00] negatives, object store is private only. [30:03] You cannot do a public bucket. That [30:04] burned me real bad on a project that I'm [30:06] now migrating off of railway storage. [30:08] Free egress is a ticking timer in my [30:11] opinion. No one offering egress for free [30:12] can maintain that forever. Like there's [30:14] always a catch. and I am a little scared [30:15] of what that catch will be with railway. [30:17] This is the type of complaint that I [30:18] might have for other things if I use [30:20] them more, but as a pretty heavy Railway [30:22] user, I see the flaws more and the [30:23] dashboard can get into some weird [30:25] states, especially around DNS and SSL [30:28] stuff. You don't buy domains on Railway. [30:30] I bought mine on Versel, but then I set [30:31] it up on Railway and SSL was broken [30:34] forever. The dashboard just wouldn't [30:35] verify the CNAME. It just it took a [30:37] while to get that working and I didn't [30:38] know if I was doing it right last time [30:40] because the UI didn't really indicate [30:41] what the current state was very well. [30:43] Thankfully, I just left it alone for [30:45] half an hour, went back and it was good. [30:47] Not clear that was happening though or [30:48] if it would or wouldn't work. Oh, and [30:50] the egress does cost 5 cents per gig for [30:53] services, but the object storage has [30:56] free egress, but you are paying 1.5 [30:58] cents per gig per month for the storage. [31:00] So, know that I got the previous storage [31:02] price from Jake. He might have just [31:03] typed it, but 1.5 cents per gig is [31:05] pretty good price for the storage. I [31:07] might rethink some things based on that. [31:09] There's a lot more benefits to them [31:10] though than we've gotten to here. [31:12] supports everything. Best DB setup I've [31:15] ever had. Like the way that you link [31:16] services together and all of that is [31:18] just so pleasant. Config is generally [31:20] great. Perf is insane. They're racking [31:22] their own servers and they're good [31:24] servers. I also think that the server [31:25] firm I'm using for US West is pretty [31:27] close to me, which makes it feel just [31:29] absurdly fast. I'm just very happy with [31:31] Railway. I'll call pricing fair overall. [31:35] There are very few things on Railway [31:36] where I'm like, that's too expensive, [31:37] and the one that I thought was, I was [31:38] just wrong about. Oh, they do have [31:40] previews and oneclick roll backs. That's [31:41] good to know. The one-click rollbacks is [31:43] huge and has saved me a ton of times. [31:44] Depending on how you use the platform [31:46] might even save you a shitload of money. [31:47] Some customers who were on AWS before [31:49] were able to cut their cost by 90% by [31:51] moving to Railway and also get better [31:53] experience. It's It's really good. I'm [31:55] super happy with Railway. I bet you will [31:56] be too. They are probably my top pick [31:58] here. One last thing on Railway before [32:00] we get to EC2. They just raised $100 [32:02] million. They're not going anywhere. [32:04] They were already nearly profitable [32:06] before. They might have actually been [32:07] profitable for a bit. They are not going [32:09] anywhere. AWS also never going anywhere. [32:12] Super reliable, like disgustingly [32:15] reliable, supported by everything, great [32:18] locations, so you know that they'll [32:20] network with everything fast. Like every [32:23] service tries to get themselves into AWS [32:25] server farms so that you can have low [32:27] latency with AWS EC2. The amount of [32:30] integration that they have with like [32:31] everything is nuts cuz everyone's built [32:34] it. Platforms like Terraform and Palumi [32:36] are largely built around EC2 and EKS. [32:38] And hell, Kubernetes is largely designed [32:41] around how EKS works at this point. Like [32:42] everything is building for EC2. Like if [32:46] it doesn't support EC2, I am sus as [32:47] hell. Guaranteed SLAs, reliability, all [32:49] the things you need there. Bargate's [32:51] dope. There's tons of other services you [32:53] can integrate alongside EC2 within AWS [32:55] and externally that are insane. And most [32:57] importantly, no one's ever been fired [32:58] for picking AWS. It's the default. And [33:00] it's the default for a reason. It is [33:02] good. But there are negatives. cost is [33:04] surprisingly higher than competition. [33:06] Their pricing is so annoying that [33:08] usually you go use another service to [33:11] look at it because it's just their [33:13] pricing is God, they hide all this info [33:16] so deep. Here we go. Sadly, this chart [33:18] is doing hourly pricing, not monthly. [33:21] Time 24* 30. And there's a reason why. A [33:24] 2 gig 1vcpu box with just EBS storage is [33:29] $22 a month. [33:32] If we're talking EKS, you're going to [33:33] want the beefiest nodes you can [33:34] reasonably fill. So, you can choose 190 [33:37] core Graviton box. Yeah, it's it's [33:39] pretty nuts. AWS not only charges a [33:43] significantly higher price than what I [33:45] would expect for the tier of hardware, [33:47] they don't really lower those prices. [33:50] So, it's kind of just like a fee you're [33:51] paying forever on a box that's probably [33:53] 6 plus years old and you're paying as [33:55] though it's brand new. It's bad. It's [33:57] crazy. Everybody always advertises like [33:59] AWS is the cheap option. It's not. In [34:02] many cases, Versell is actually cheaper [34:04] than AWS. Just depends on how you're [34:05] using them. And if you're doing stupid [34:06] things on either, you can screw [34:08] yourself. It's no surprise railway comes [34:10] out cheaper as often as they do. So, [34:11] yeah, cost is not the thing you are [34:13] saving. Setup isn't the thing you're [34:15] saving either. You basically have to [34:17] build a solution to handle your [34:19] deployments on AWS. There have been [34:22] multiple billion plus dollar companies [34:23] built just because setting up on AWS is [34:26] too hard. Everything from Terraform to [34:28] versel is arguably because AWS sucks to [34:31] config dashboard is Cloudflare tier UX. [34:35] It at least works though. It's rare on [34:37] the AWS dashboard and things are just [34:38] outright broken like they are on [34:40] Cloudflare, but getting around it is [34:42] hellish. Oh god, the permissions. I [34:46] god that's so many throwbacks. I I have [34:48] been to hell with AM. It's so bad. It's [34:51] so [ __ ] bad. I I'd put this in the [34:54] same bucket honestly as I put GCP and [34:56] Azure. Now, if you're coming to me or a [34:58] channel in a video like this for advice [35:00] on where to deploy, don't deploy to AWS. [35:03] Seriously, don't. We've went over all of [35:05] these options. You hopefully understand [35:08] what the values are for each of them. If [35:10] I was to tier these, I'm going to ignore [35:12] the ones I wouldn't recommend. I'll say [35:14] top Rex, the ones that I would [35:16] absolutely recommend, I think everyone [35:17] should at least consider, Railway, [35:19] Versell, and Render. all easy. S tier, [35:22] you're good. I have a specific need [35:24] tier. I would put Netlefi if they have [35:27] some specific integration or their [35:28] queuing stuff works really well for you. [35:30] Cloudflare if you're willing to deal [35:32] with the compromises around not having a [35:34] proper node environment. Very [35:35] beneficial. Or you're just trying to [35:37] microoptimize for costs at crazy scales. [35:39] Really good option as well. Maybe Hner. [35:42] It hurts to put it here, but if your [35:44] goal is to have the cheapest possible [35:46] thing with insane free egress that's [35:49] just hosted and you're okay with it [35:50] being slow and unreliable, it can be [35:52] fine. I wouldn't confidently tell you [35:53] like, oh, go move that to Hner, but it [35:55] is an option worth considering. Oh, and [35:58] Fly, absolutely Fly.io. While it might [36:00] not still exist in a year or two, it has [36:02] some really compelling offerings that [36:04] nothing else does. There's a good chance [36:05] you run into a problem Fly uniquely [36:07] solves. Worth considering if you do. And [36:09] then I have the you won't listen anyways [36:11] tier. This is for people who watch these [36:14] videos for fun but can't realistically [36:16] take my recommendations for all sorts of [36:19] different reasons. This is where I'd put [36:21] most of the AWS offerings like Lambda [36:23] and EC2. I'd also put GCP in here, [36:26] Azure, IBM Cloud, things like that. Like [36:29] if your employer already chose it for [36:32] you, it's fine. And pretty much [36:34] everything else, I don't think I can [36:36] recommend it. Now, if you pick anything [36:38] here, you're probably well set. If you [36:40] pick anything here, I hope you have a [36:42] good reason. And if you pick anything [36:43] here, I hope it was your boss that [36:44] picked it, not you. Now, you know how I [36:47] think about these things. And hopefully [36:48] you can now better understand why almost [36:50] everything I deploy is on Versel and [36:52] Railway. And maybe in the future render [36:54] as well. Yeah, and we barely even talked [36:56] about CDNs. What a video. I hope this [36:59] helps you better understand what these [37:01] platforms are, what benefits and [37:02] negatives each have, and maybe, just [37:04] maybe, you'll have more confidence when [37:05] you pick the next place you host. Let me [37:07] know how y'all feel. And until next [37:09] time, please stop flaming me about [37:10] Hutner. I really don't care about your [37:12] $5 VPS.  ## 📺 Video ![](https://www.youtube.com/watch?v=yfxDdQo2cyI) --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: Where Should You Deploy In 2026? ## 🧰 Action Inbox - [H1] Evaluate serverless-first approach — most apps fit serverless model — 00:00 #deployment - [H2] Consider bandwidth costs carefully — can drive unexpected bills on Vercel — 15:45 #cost-optimization - [H3] Avoid Hetzner for production — reliability and support issues — 22:30 #platform-selection ## 🧭 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 - [Vercel](https://vercel.com) - [Railway](https://railway.app) - [Render](https://render.com) ## 📝 Summary - Comprehensive comparison of deployment platforms for 2026, covering serverless and VPS options - Recommends starting with serverless solutions (Vercel, Railway, Render) for 98% of applications - Key factors: developer experience, cost transparency, reliability, and platform longevity - Top tier recommendations: Railway, Vercel, Render based on overall value - Warning against platforms with poor support (Hetzner) or confusing pricing (AWS for small teams) ## 📖 Main Content This analysis breaks down deployment platform choices into serverless and VPS categories, with detailed evaluation of developer experience, pricing, reliability, and business sustainability. The recommendation strongly favors serverless-first approaches, as most applications can be successfully deployed without traditional servers. The evaluation considers both technical capabilities and business factors like platform longevity, noting recent industry consolidation and the risk of platforms disappearing. Particular attention is paid to hidden costs like bandwidth charges and seat pricing that can dramatically impact total cost of ownership. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/yfxDdQo2cyI?t=0) — [H1] Introduction and Approach - Key idea: Breaking down deployment options into mental models for decision-making - Evidence: "I'm trying to help you make a mental mapping and model for how to choose the right place to host your code" #### ⏱️ [03:15](https://youtu.be/yfxDdQo2cyI?t=195) — [H2] Serverless vs VPS Framework - Key idea: Start with serverless unless you have specific server needs - Evidence: "98 plus% of applications can be served totally fine in a serverless deployment solution" #### ⏱️ [04:30](https://youtu.be/yfxDdQo2cyI?t=270) — [H3] AWS Lambda Limitations - Key idea: Lambda has significant setup complexity and concurrency issues - Evidence: "Lambda is not trivial to set up... Concurrency is not viable" #### ⏱️ [06:45](https://youtu.be/yfxDdQo2cyI?t=405) — [H2] Cloudflare's Unique Architecture - Key idea: Cloudflare uses isolates instead of containers for better cold starts and pricing - Evidence: "Instead of handing them a box with a kernel... you're handing them a JS file" #### ⏱️ [09:20](https://youtu.be/yfxDdQo2cyI?t=560) — [H3] Cloudflare Node.js Compatibility Issues - Key idea: Not running true Node.js creates package compatibility problems - Evidence: "Things like sharp and ffmpeg, you're not running anything that is written in a language other than JavaScript" #### ⏱️ [11:30](https://youtu.be/yfxDdQo2cyI?t=690) — [H3] Cloudflare Dashboard Problems - Key idea: Cloudflare's developer experience is severely hampered by poor tooling - Evidence: "The dashboard is absolute garbage... should be deleted and restarted from scratch" #### ⏱️ [13:45](https://youtu.be/yfxDdQo2cyI?t=825) — [H2] Netlify as Solid Alternative - Key idea: Netlify provides reliable Lambda wrapper with good integrations - Evidence: "I've never regretted my use of Netlify in a meaningful way" #### ⏱️ [15:15](https://youtu.be/yfxDdQo2cyI?t=915) — [H1] Vercel as Gold Standard - Key idea: Vercel remains easiest and most consistent deployment experience - Evidence: "Still by far the easiest and most consistent way to deploy most apps" #### ⏱️ [17:30](https://youtu.be/yfxDdQo2cyI?t=1050) — [H3] Vercel Bandwidth Cost Trap - Key idea: CDN bandwidth charges are the primary cause of shocking Vercel bills - Evidence: "Every time I see one of those viral bills... All but one of those instances, it was bandwidth" #### ⏱️ [20:45](https://youtu.be/yfxDdQo2cyI?t=1245) — [H3] Hetzner Reliability Concerns - Key idea: Hetzner has serious account management and reliability issues - Evidence: "They didn't like that I signed up with a Gmail account, so I got auto flagged" #### ⏱️ [23:15](https://youtu.be/yfxDdQo2cyI?t=1395) — [H2] Digital Ocean's Documentation Legacy - Key idea: Digital Ocean built exceptional developer resources beyond their platform - Evidence: "I would not be the dev I am today if it wasn't for the Digital Ocean documentation on how to host Minecraft servers" #### ⏱️ [26:30](https://youtu.be/yfxDdQo2cyI?t=1590) — [H2] Fly.io Innovation and Risk - Key idea: Fly.io offers unique technical capabilities but faces financial uncertainty - Evidence: "One of the most fun platforms I've ever built on. Not confident that they will still be here next year" #### ⏱️ [30:15](https://youtu.be/yfxDdQo2cyI?t=1815) — [H2] Render's Stability - Key idea: Render provides reliable Heroku alternative with solid business model - Evidence: "They make enough revenue that I'm not worried about them disappearing anytime soon" #### ⏱️ [32:45](https://youtu.be/yfxDdQo2cyI?t=1965) — [H1] Railway Excellence - Key idea: Railway combines modern DX with transparent pricing and strong fundamentals - Evidence: "Railway makes me smile every time I use it... They just raised $100 million" #### ⏱️ [37:20](https://youtu.be/yfxDdQo2cyI?t=2240) — [H2] AWS Cost Reality - Key idea: AWS is surprisingly expensive compared to modern alternatives - Evidence: "A 2 gig 1vcpu box with just EBS storage is $22 a month" ## 📚 References - [Vercel Platform](https://vercel.com) - [Railway Cloud](https://railway.app) - [Render Hosting](https://render.com) - [Cloudflare Workers](https://workers.cloudflare.com) ## 🗣️ Paraphrase - Most applications should start with serverless platforms because they handle 98% of use cases without the complexity of managing servers - The top recommended platforms (Railway, Vercel, Render) offer the best combination of developer experience, transparent pricing, and business stability - Hidden costs like bandwidth charges can dramatically impact total cost, making careful platform evaluation crucial for long-term success ## 📰 Newsletter **Platform Selection Made Simple: Your 2026 Deployment Guide** Choosing where to deploy your applications doesn't have to be overwhelming. Start with the serverless-first principle: if you're unsure whether you need a server, you probably don't. **Top Recommendations:** - **Railway**: Modern DX with transparent pricing and $100M funding - **Vercel**: Best GitHub integration, just watch bandwidth costs - **Render**: Reliable Heroku alternative with enterprise backing **Key Takeaway**: Focus on platforms with clear pricing, good developer experience, and strong business fundamentals rather than chasing the cheapest options. Resources: [Railway](https://railway.app), [Vercel](https://vercel.com), [Render](https://render.com) ## ✅ Action Items #### DevRel - Developer advocacy: Create platform comparison workshops for different use cases - Education: Develop cost optimization guides for each recommended platform - Developer experience: Document migration paths between platforms - Developer marketing: Share real-world deployment cost breakdowns - Community management: Moderate platform recommendation discussions #### OSPO - Policy & Governance: Establish platform evaluation criteria for open source projects - License Compliance: Review platform terms for open source compatibility - Security Management: Audit platform security practices and compliance - Software Inventory: Track which projects use which deployment platforms - Developer Support: Provide platform selection consultation - Community Engagement: Fund community infrastructure on recommended platforms - Strategic Alignment: Align platform choices with organizational goals #### Community - Maintainers: Provide deployment platform recommendations in project templates - Contributors: Create getting-started guides for each platform - Sponsors: Negotiate community discounts with recommended platforms - Ecosystem: Coordinate platform evaluations across related projects #### WordPress - Core: Evaluate deployment options for WordPress.org infrastructure - Core Performance: Test performance across different hosting platforms - Community: Create WordCamp deployment workshops - Training: Develop hosting selection curriculum - Marketing: Document WordPress hosting best practices - Support: Build knowledge base for common deployment issues - Design: Create platform comparison visualization tools - Documentation: Update hosting recommendations in official docs - Meta: Evaluate .org infrastructure platform choices - CLI: Add deployment commands for recommended platforms - Hosting: Partner with community-friendly hosting providers - Openverse: Optimize deployment for media-heavy applications #### The WPCC - Programs: Fund community hosting for qualifying projects - Projects: Sponsor migration away from unreliable platforms - Funding: Provide hosting grants for open source WordPress projects #### FAIR - Technical independence: Avoid vendor lock-in through platform standardization - Policies: Establish platform evaluation transparency requirements - Governance artifacts: Document platform selection decision processes ## 🧪 Hypotheses - Serverless platforms will continue consolidating around developer experience leaders - Bandwidth costs will become increasingly important as applications become more media-rich - Platform business model sustainability will become a primary selection criterion - Developer experience quality will increasingly differentiate similar platforms ### 📊 Methodology - Compare total cost of ownership including hidden fees across platforms - Test deployment workflows and developer experience for common use cases - Analyze platform business fundamentals and funding status - Survey developer satisfaction and migration patterns ### ❓ Questions - How will AI-assisted deployment tools change platform selection criteria? - Which platforms will successfully transition from startup funding to sustainable revenue? - How will edge computing adoption impact serverless vs VPS preferences? ### 🔮 Future Research - Long-term cost analysis across different application growth patterns - Developer productivity metrics comparison between platforms - Platform reliability and uptime analysis over extended periods ### 💡 Implications - Practice: Standardize on 2-3 platforms to reduce operational complexity - Policy: Establish clear platform evaluation and migration procedures - Security: Regular platform security posture assessments required - Education: Platform-specific deployment training becomes essential - Funding: Budget for potential platform migration costs and bandwidth scaling ### 🧠 Learning Styles Assessment Reading level estimate: 10th Grade (Flesch-Kincaid) #### 👀 Visual learners - Present: Platform comparison charts, pricing tables, architecture diagrams - Improve: Cost breakdown visualizations, deployment flow diagrams #### 🔊 Aural learners - Present: Video format with detailed explanations and examples - Improve: Audio-only version for commuting, podcast episode format #### 🗣️ Verbal learners - Present: Clear terminology definitions, platform analogies, specific examples - Improve: Glossary of deployment terms, platform comparison narratives #### 🧩 Kinesthetic learners - Present: Step-by-step deployment examples, hands-on platform trials - Improve: Interactive platform selection tool, deployment checklists #### 🧠 Logical learners - Present: Decision trees, cost comparisons, feature matrices - Improve: Platform scoring rubrics, ROI calculations, migration timelines #### 🧑‍🤝‍🧑 Social learners - Present: Community discussions, shared experiences from other developers - Improve: Platform user communities, peer review sessions #### 🧘‍♀️ Solitary learners - Present: Detailed written analysis, self-assessment tools - Improve: Personal deployment strategy worksheets, reflection prompts #### 🌿 Naturalistic learners - Present: Platform ecosystem connections, growth pattern analogies - Improve: Sustainability impact comparisons, environmental considerations ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy, descriptive link text - Improve: Alt text for comparison charts, table headers for pricing data #### Keyboard navigation - Present: Video player keyboard controls, logical tab order - Improve: Skip links for long content sections, keyboard shortcuts #### Contrast and readability - Present: High contrast text, readable font sizes - Improve: Color-blind friendly chart colors, adjustable text sizing #### Text resizing and reflow - Present: Responsive layout at 200% zoom - Improve: Maintain readability of comparison tables at high zoom #### Media and captions - Present: Video with spoken content, visual demonstrations - Improve: Detailed captions, audio descriptions for visual comparisons #### Forms and interactions - Present: Interactive elements for platform comparison - Improve: Clear error messages, accessible form validation #### Standards reference - Follow WCAG 2.2 AA guidelines for all comparison tools and interactive content ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global platform availability considerations, multi-region examples - Improve: International pricing variations, local compliance requirements #### Inclusive language - Present: Clear technical explanations, defined jargon - Improve: Alternative explanations for complex concepts, avoid cultural idioms #### Neurodiversity support - Present: Structured content with clear sections, consistent formatting - Improve: Executive summaries, progressive disclosure of complex information #### Representation - Present: Varied use cases and developer backgrounds - Improve: Diverse example applications, inclusive imagery #### Psychological safety - Present: Respectful platform comparisons, acknowledgment of different needs - Improve: Non-judgmental language about platform choices, supportive tone ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear criteria applied consistently across platforms - Inductive strength: Patterns identified from specific platform experiences - Causal reasoning: Links between platform choices and business outcomes - Analogical strength: Appropriate comparisons between similar platforms #### Fallacies - Ad hominem: Some personal attacks on Hetzner beyond business concerns - Appeal to authority: Heavy reliance on personal experience without broader data - False dilemma: Occasional oversimplification of complex platform tradeoffs #### Tone of voice - Overall tone: Opinionated but informative, with clear bias toward specific platforms backed by experience ### 🛡️ DARVO Analysis - Deny: No significant denials of legitimate platform concerns - Attack: Some harsh criticism of Hetzner and Cloudflare that may exceed balanced assessment - Reverse victim/offender: No victim/offender role reversals identified - Emotional c --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=yfxDdQo2cyI)* **[00:00]** Today's video is going to be a bit different, because I wasn't actually filming this video when I filmed most of this video. I know it sounds crazy, but just hear me out for a sec. I was just filming a video about the death of Heroku. You might have even seen it already. And that video ended up with a long tangent about various other alternatives that you might consider moving to. Everything from AWS to Vercel, Railway, Netlify, Render, Cloudflare, DigitalOcean, Hetzner, Fly, and more. I wanted to do my best to break all of these options down and share how I think about them and how I choose where I deploy my applications. **[00:31]** While I have been sponsored by many of these companies in the past, none of them are sponsoring this video. The point of this was to give you my honest take on how I choose where I deploy my services. It can feel a little overwhelming to choose, and a lot of the advice I see around the internet feels like it's coming a little bit too much out of the perspective of the user in the specific thing they are working on in that moment. Where all of these platforms, okay, most of these platforms have real benefits that are worth considering. There are at least three options on each side here that are worth **[01:02]** thinking about [snorts] and evaluating before making a decision. And this video isn't just like, "This one's good and this one's bad." I'm trying to help you make a mental mapping and model for how to choose the right place to host your code. And in a world where we're deploying more and more services, making all these micro apps, and vibe coding all sorts of stuff, no one's helping you figure out where to put it. And if I keep seeing these crazy Vercel bills or people getting stuck trying to deploy on AWS, I'm going to go mad. I really want to help you guys understand how I pick solutions, and it's not based on who's paying me. None of these companies are **[01:33]** paying me today. The only one who is is today's sponsor. I have a confession to make. I've stopped using GitHub for CI, because today's sponsor Blacksmith has made my CI so much better. Actions just aren't reliable, and I've had so many problems with them. And they all vanished as soon as I set up Blacksmith for all of our repos. And yes, I mean all of them. Looks like we even have jobs running right now. Honestly, all of the observability stuff would be worth it by itself. Actually seeing what failed and why, and having a log search that like works. If you've ever had to debug weird actions, you know how absurdly useful this is by itself. It is **[02:04]** not just for individual projects, you can scan all of your projects as well, which is huge. But, the real key is the fastest part, because they really are the fastest. The secret to how they're so fast isn't really that secret. They're using better hardware with gaming CPUs as well as NVMe drives that store all of your layers for things like Docker, which allows the restoration process to be instantaneous instead of taking forever. I just moved for a Rust project I'm working on, and they went from 5 minutes to under 30 seconds. We've seen similar speed-ups across all of the projects that we're working on. Other companies like Ashby doubled their deployment speeds while also cutting **[02:35]** their spend by 75% because, yes, Blacksmith is cheaper, too. Don't believe me? Try it yourself. It's free to get started, and it's one line of code changed. Yes, really. You swap the action once you're set up, it's good to go. Stop wasting your time and speed up your builds at soydev.link/blacksmith. I'll break this into servers and serverless. You know, we'll call it VPSs and serverless. There's a lot of good options for both. In the serverless side, obviously, Vercel is still inarguably king. The balance of DX and capability of the platform is pretty hard to beat. Netlify is not a bad **[03:07]** option, especially with their recent embrace of Vibe coding and supporting all of the platforms that build all the fancy Vibe coding tools. Scales great. I love the CEO. Really good. Has its negatives, we'll get there. And then, we have Cloudflare. A lot of things to say about that. On the VPS side, we have a ton of options. Obviously, we can go AWS with EC2 or EKS. Lots of options there. Railway, which we've already talked about. You have Render, Fly.io. You have DigitalOcean. Another crazy throwback. Man, I have DigitalOcean, I have a long-ass history. Oh, yeah, Hetzner. The **[03:39]** classic. That's the one I was forgetting. Obviously, there's other traditional clouds like GCP, Azure. The reality is that if either of these are the right solution to your problem, you already know that, and you're not here for me to tell you about different options. There's also OVH. None of the rest are things I care about enough to put in the list. I think this is a good enough list of the VPSs. I'm going to start by diving into the serverless list here. If you don't know which of these you fit under, you should almost certainly start with the serverless options. And if they have issues because you actually do end up needing a server, **[04:09]** you'll figure that out pretty fast, and then you'll move over accordingly. But generally speaking, 98 plus percent of applications can be served totally fine in a serverless deployment solution. I would lean in that direction. Just being a fair point that AWS Lambda should also be in here. You're not wrong, but we're not going to be talking about that one too much. Let's break down all these options and how I pick between them. I honestly think this will be easier if we go backwards. So, let's start with AWS Lambda. Lambda is not trivial to set up. There are lots of tools to help like **[04:39]** SST, Pulumi, Terraform, things like that. It still sucks. Concurrency is not viable. They are starting to introduce their concept of doing concurrent Lambda stuff. They're not there yet. I don't know anyone who's actually using it or relying on it. Then there's stuff like Amplify, which is a total joke. Yeah. CDN Gateway is your problem. Get push pipeline, GLHF. Costs are fine, but concurrency sucks. Yeah. It's hard to recommend Lambda to most people. At least it's Node though, or anything **[05:10]** else. If you can put in a Docker image, you can put it on Lambda, but a lot of technologies that people like tends to be slow to spin up. So, don't think you can just rewrite your Lambda in Rust and it's magically super fast. Sometimes those things take a bit to boot, especially if your wait time isn't on the startup of your code, it's actually on the connection to your database. Good luck, have fun. There's also a lot of other little things like streaming was super broken in Lambda. I think it might be fixed now, I'm not sure. But if you're using a server component style framework that does HTTP streaming, like you know, Next.js, not fun. And next we **[05:41]** have everyone's favorite, Cloudflare. First thing I want to say is that they have one-of-a-kind infra, and that one of a kind infra allows them to be significantly cheaper than almost anything else because Cloudflare isn't using traditional servers or Docker images. You can't send a Docker image to Cloudflare and run it. Well, you kind of can now, but their whole like Docker image server thing's a different product and it sucks. I don't know anyone using it. It's super overpriced and slow. Cloudflare's strength is you give them a JavaScript file and they run it on their edge network that has a different layer of abstraction. Instead of handing them **[06:12]** a box with a kernel in it and expecting them to run it for you, you're handing them a JS file and three layers above the kernel in their custom version of V8 called WorkerD, they run your code safely in an isolate that doesn't have to spin up a whole server the way that things like Lambda do. That means that cold starts are near zero. It means that their pricing model's fundamentally different cuz they only charge on CPU time. Other platforms charge wall clock time because the server's up, it doesn't matter how many people are using it, it costs them money, it costs you money, too. With Cloudflare, if your request **[06:42]** isn't doing anything, like it's idling waiting for more data to come in, the computer on that box can be used for someone else's request because lots of people are running their code at the same time on the same box. On Vercel, every developer's deployment has its own kernel. On Cloudflare, every single deployment is just a JavaScript file running in the same VM. It also gives the performance profile meaningly. Check out the Vercel versus Cloudflare video if you want more info on that. They've made improvements since, but it's still not as fast as dedicated box can be, but there's a much bigger catch. Not Node. Every time I use Cloudflare, I run into **[07:15]** something because of this. It's not running Node.js, it's running their JavaScript engine. And because of that, a lot of things don't work. Things like reading and writing files. Things like many of the methods you use to connect to databases. Things like any package that runs any native code, you know, like image optimizers, PDF parsing, all the fun things we like to do in our servers with our Node apps. There's a lot of issues when you can't use Node. They've done their best to patch in support for a lot of node stuff. None of **[07:46]** the things I just mentioned have been fixed. All of those are still problems, but most packages have shims around the node functions now built in where they can mostly work. Things like crypto were entirely broken and now mostly work. The compat layer is fine, but you're almost certainly going to run into some issues. Like one of the biggest ones I have is stuff like sharp and ffmpeg. You're not running anything that is written in a language other than JavaScript in Cloudflare. And anyone saying otherwise, like, "Oh, you can just wasm your stuff." has not tried it seriously. I have been to hell and back for many **[08:16]** projects trying to get Cloudflare to let me do something that involves any code that isn't in JavaScript, and every single time I gave up and moved to one of the other options. Speaking of other options, Netlify. Netlify's another lambda wrapper, but they include all the other fun things like the CDN that make the platform so nice. Everything from here down effectively has those pieces. Really good GitHub integrations. Honestly, really good integrations in general. They have an awesome team. They support the hell out of open source. They're pretty good. I've never regretted my use of Netlify in a meaningful way. They've been a sponsor **[08:47]** in the past. I wouldn't be surprised if they are again in the future. Netlify's solid platform. They handle CDN and distribution stuff, but they don't have everything. The biggest thing I miss when I use Netlify is concurrency. Because again, the concurrency model for a lot of these things, including AWS Lambda, is each request gets its own instance. And for the modern way that things work, that is not pleasant. Their solution for this is some really cool background jobs and queue type stuff. The work they have done for their **[09:17]** queuing things is actually really, really cool. The bit I played with it for was awesome. They were way ahead of Vercel with the workspace thing. They had it figured out early, and it was surprisingly cheap. I should also mention for the Cloudflare stuff before I forget, GitHub integration. GLHF. Getting your Cloudflare stuff integrated with modern tools is still your problem, not theirs. The dashboard is absolute garbage. I I actually think that the entire dashboard code base should be deleted and restarted from scratch. There is no recovery at this point. They've had multiple massive global **[09:48]** outages because of bad code for fetching data in the dashboard. It's pretty pathetic. Addy just jumped in saying Cloudflare Pages has native GitHub integration. Awesome. Cloudflare Pages is also dead. They are merging it with Cloudflare Workers now and they've done a terrible job documenting those changes and I never know where I'm going when I'm trying to deploy on Cloudflare anymore. I had so many problems the last time I tried to deploy on Cloudflare that I sent to the team. The poor exec who was in the room with me when I did this wrote over seven pages of notes at a 10-point single-spaced font that she **[10:19]** then presented to the entire org and got like half or so of the things fixed. They are trying. Cloudflare does care a lot, but the experience is just so far behind any of the competition that's at all more modern. Just go try to deploy a random Vite React app on Cloudflare and on Vercel and then make a change and see how hard it is to deploy on those two things. It's just not pleasant. But what you're getting for that cost of your sanity is way cheaper overall. There are issues with the cost side though because **[10:50]** they're not very transparent about what free things stay free. They don't charge for egress in a bunch of cases, which is huge cuz it means if you're doing a lot of data transfer, it is cheap or free. But at a certain point, they might strong-arm you into the enterprise plans where those things suddenly do cost money. So, if it's free on the free tier or free on the base tier, that does not guarantee it stays free in the enterprise tiers. So, know that cuz it's very important. One last really great thing they did though, they hired Dylan. If you're not familiar, Dylan Mulroy is one of the like wizard TypeScript devs powering all sorts of tools in the **[11:20]** background. One of the people that's really pushed Effect-TS to where it is today. Fellow JJ nerd. Great developer overall. Love Dylan to death. He was at Vercel and cared a lot about DX there. He's now at Cloudflare and he's pushing the limits of DX there as well, trying to fix a ton of stuff. In his first week he filed like 20 PRs to the Wrangler CLI and all these other random things. There's a good chance that Dylan will be able to fix a handful of the things in this list, but right now Cloudflare has the second worst DX compared to AWS. In many ways I would argue it's worse than AWS because it changes all the time and **[11:52]** is never well documented and nothing ever makes sense. It's actually so unclear what you can and can't do on Cloudflare because the docs are just wrong and lie a lot. It's it's rough. And now for the exact opposite experience, Vercel. I have my issues with Vercel, everyone does. Watch my breaking up with Vercel video if you want to see some of them. There's a lot of them, but they are still by far the easiest and most consistent way to deploy most apps. Basically everything I have shipped to the web over the last few years has been on Vercel at the very least for the web app for it cuz it's **[12:24]** just a really easy way to do that. The GitHub integration's great, the free tier is great, the billing model makes sense, the integrations with everything are awesome. Honestly, I can just copy this part as well as this part. Obviously it's the best place for Next.js Regardless of how you feel about Next, even I'm coming around to not liking Next too much nowadays. Obviously they handle the CDN distribution stuff. And the parts where we start to really differ from the competition, Fluid Compute. This is the thing I talked about before. It's their attempt to do similar pricing to what Cloudflare does **[12:54]** with the CPU time pricing. It has helped a ton. They also consistently introduce cool primitives to the infrastructure to take advantage of these things like the workflows stuff. I know you guys don't love the whole syntax of directives with use workflow and whatnot, but it is really cool what it can do. It's a good way to get started with that type of building if you want more reliable services. It is what it is. There are negatives though. Cost is still an issue. Not just CPU cost. I would actually argue for most apps the cost difference between Vercel and Lambda is **[13:26]** in favor of Vercel for the compute side because of the concurrency stuff in particular. That just knocks costs down a shitload. But they do things with the costs that still aren't great. Things like the $20 per month seat pricing, very annoying. Every time I have to add a new dev to the team, I'm just increasing my Vercel bill. Don't love that. But the biggest cost when you're shipping real software is almost never going to be the compute or the seat pricing on Vercel. Bandwidth. Every time I see one of those viral bills where it's like, "Oh my god, Vercel cost me **[13:56]** $5,000." All but one of those instances, it was bandwidth. Because Vercel has a very aggressively positioned CDN that has the goal of making everything as fast as possible. All of the code that Vercel ships for you, the things that go to the users, like your HTML pages, your JS bundles, your SVGs, all the things that are coming out of your code base that are going to the user, those are all on Vercel's CDN. It is obviously meant for things that are small and need to be loaded quick. Like, you know, JavaScript files that power your site. But if you're filling up your public **[14:27]** folder in your project with a ton of big assets, like 50 MB video files or 10 MB PNGs or 5 to 10 MB MP3s, that's going to cost a lot. It's almost like you're trying to use a race car to pick up groceries. Not only is it going to fit fewer groceries, it's going to use more gas and probably cost you more in maintenance. It is not the right solution for any static asset that is bigger than like 400 KB. They do offer their own file storage solution called Blob that is built on top of R2, funny enough, the Cloudflare product. I don't **[14:58]** know how hard they're focused on it now. It doesn't really seem like a thing they care a lot about. Thankfully, you can use UploadThing, a weird file upload service some random YouTuber made. Don't think about that part too much, but uh it's a lot cheaper. Doesn't charge for egress. Worth considering. So, that's why I default to Vercel. As long as you're careful about the bandwidth and where you're putting it, it ends up being really good. The GitHub integrations are best in class. The CLI is really good. It's easy to set up. It works with everything. It's real Node, so you can do anything you can do in Node.js. It's pretty good. Generally speaking, if it doesn't work on Vercel, **[15:28]** it's probably because it's a bad workload for serverless in general. It is very rare that I find it worthwhile to move off of Vercel to another serverless provider, unless it is some crazy weird compute thing that Cloudflare happens to be cheaper for. But even that's getting rarer now with the fluid compute pricing. Cool. So, let's say you're one of those people that just cannot use serverless. There are a lot of people that that is the case for, and there are even more people that that isn't the case for, but occasionally have a project that benefits from traditional servers. Let's **[15:59]** look at our options for that. Let's start with the easy ones to make fun of. Hetzner and OVH. Benefits: really cheap. People on Twitter will think you're cool. Negatives: uh your account can get canceled at any time, especially with Hetzner. I've even experienced this. They didn't like that I signed up with a Gmail account, so I got auto-flagged and my account couldn't deploy for a long ass time. It was bad. And I've seen that story so many times. I've even seen people's production environments getting taken down because some random policy change resulted in their account not having **[16:31]** some checkbox hit. They are known for banning. They are known for flagging. A lot of people have had a lot of problems. Immediately I get [ __ ] for talking [ __ ] on Hetzner, but I don't care. I've exclusively had bad experiences with Hetzner, and I need y'all to know that. OVH is some amount better, but honestly they're also slightly more expensive, so I rarely find it is worth it. The product offerings also lacking. Like no integrations with anything. >> [snorts] >> If you're using Hetzner, you're managing your deployment pipelines, you're managing your methods for allocation, you're managing your hierarchy for like **[17:01]** what servers are being routed to and from, your gateways, your CDNs, everything. They're not doing [ __ ] for you. They're giving you a VPS in a box that they own somewhere random. Also of note, uh locations kind of suck. The best prices are for the EU servers, but even the EU servers aren't co-located with other important things. Like if you're using, I don't know, PlanetScale for your database, the likelihood that the PlanetScale database in the Hetzner database are on the same network is basically zero, which means you're adding a shitload of latency and making your service significantly slower and **[17:31]** worse, so that you can look cool on Twitter for paying five bucks a month instead of six. It's just not worth it. I I don't know any serious people who are building on top of Hetzner. I just don't. It's all hobbyists. And that's fine if you want to just be a hobbyist and really micro optimize your costs. I don't believe that you're real. I just don't. Not a Hetzner fan. I'm sure my comment section is going to be wonderful now that I've said that. Next, we'll talk about DigitalOcean. This is one I have a ton of experience with. First benefit is the docs, best in class. I In **[18:04]** chat, tell me if you're old enough to have been there with me. Ones in the chat if you've also relied on the docs for DigitalOcean for deploying Minecraft servers places other than DigitalOcean. I know that's been the case for me. I would not be the dev I am today if it wasn't for the DigitalOcean documentation on how to host Minecraft servers. Look at that, chat. A lot of us have been there. Crazy throwback, but man, the amount of quality documentation that they have had forever now is just unbelievable. Like to this day, I'll Google search some weird thing I want to **[18:34]** do with SSH or GNU screen or some thing I want to deploy. There's a 50% chance that DigitalOcean is one of the first results, and not even how to do this on DigitalOcean, just how to do this. And if you choose to use DigitalOcean, you can. They really took that angle seriously of just being a good resource for developers. They have since laid off a lot of the staff that wrote those docs, but god damn were they useful for a long long ass time. Even like pre-Stack Overflow days. Other benefits of DigitalOcean, they've been around forever, so they're probably not going anywhere. They have good integrations, **[19:05]** not great, but good integrations to things like GitHub. I'll call it decent integrations. And a lot of companies that we use things from here are using them. From Bright Data to Falt, Character AI and more. Like they're they're a real legit company that's being used by a lot of real legit products, unlike some of the other options here. We need to take a look at the pricing though, cuz it's not cheap. They're immediately starting with their GPU boxes, which is cool that they offer those, but the compute less great. They do still have a free tier, but droplets Oh, they're now per second pricing. **[19:36]** Their base tier at 512 meg, 500 gigs of transfer, 10 gig drive is four bucks a month. One gig is up to six. And just for comparison sake, we'll look at Hetzner's pricing. They got boxes with four gigs of RAM and 40 gig SSDs and up to 20 terabytes of traffic for four bucks a month. This is why people choose Hetzner. It is also worth noting that it's in Germany or Finland, and I don't think the US locations are even visible in the pricing charts. Or is it regular performance? That's Okay, cool. Regular **[20:06]** performance at different tab than the cost-optimized ones. And those ones have US locations. And now we're up to six bucks for the two gig 40 gig plan. That's a lot closer to what we were seeing over here. So it as crazy as it seems, do you understand how hard Hetzner works to make the price look incredible, even though there are catches? Like again, we have to hit this button to get real locations, and immediately the price skyrockets. Turns out that the two vCPU 4 gig boxes in Germany in regular **[20:38]** performance mode, not cost-optimized mode, is more expensive than Digital Ocean. And if you want a dedicated box so that you never have to worry about performance degrading, you're now at 14 bucks a month minimum for again, rather small Okay, it's 8 gigs of RAM, so a little bit better. But 28 bucks for 16 gigs a month, meh, not great. Regardless, pricing is reasonable across these options so far. We have not gotten into the things that are massively overpriced. Okay, admittedly, two gigs of RAM and one vCPU for 12 bucks is a little expensive. Digital Ocean is not **[21:08]** the cheap option. It never was. If you're optimizing on that level, it's hard for me to take the work you're doing seriously. Like a $2 a month difference across servers is not something I care about cuz the time it takes to build those things is a lot more. Hell, the inference I use to build those things is a lot more. I'm paying 200 bucks a month for Claude and for Codex right now. 5 bucks a month is whatever. So, what are the negatives? How do I put this? Digital Ocean feels a little lost right now. They don't really know what their core offering is. You can even tell from the home page. The inference cloud built for scale. What? **[21:40]** That's not what I've I don't know anyone using Digital Ocean for inference right now. I've never met a person who does that. Oh, look at that. They have an open cloud shoutout on the home page now. They're leaning so hard and they're trying to find new customers, which suggests, and this is the scary part, they may be circling the drain. Of the options I have in this list, they are in the top section of most likely to have the same problem that we're talking about here right now. So, yeah, if your goal is to not have to deal with this type of migration because of the Heroku death, I can't guarantee with Digital **[22:12]** Ocean that you won't have to experience that again. So, know that going in. Definitely feels a tad dated and it feels like the compute isn't their focus anymore. They really seem to be leaning into the inference side, which good for them, but there's way more competition there and I'm not confident that they can have a meaningful impact. What do we have next? We covered these ones. Let's hop into Fly.io next. Fly.io is dope. They were a sponsor in the past. I hope they might be in the future, but they did recently have to do layoffs and I chose to cut them off as a sponsor at that point because it felt really bad taking money from a company that just **[22:42]** laid off a bunch of the staff that I was working with. Really good stuff overall and they're also a huge member of like the Elixir community, which is obviously near and dear to my heart. So, benefits. Elixir native, which I absolutely love. World-class DX. For deploying servers, they have some of the best DX in the world. Things like the way it integrates with GitHub, how you manage things in the dashboard, the clarity in what's going on where, the tools for linking different things together, preview environments, sleeping servers, all of those types of things, great. They're also huge OSS supporters. They help **[23:12]** sponsor everything from like the Elixir ecosystem in Gleam, Rails, and many other things I'm almost certainly going to forget if I try to list them off. They are just a good player in the space. More so than anyone else we've talked about so far, I would argue, they are actively, meaningfully contributing to the development of important open-source technologies to the point where it is hurting the business. Okay, people are saying they might not sponsor Gleam. Maybe they're not sponsoring Gleam anymore. I'm pretty sure they did in the past, but they are not necessarily doing great financially. Again, layoffs, and I **[23:44]** haven't heard anything about them raising anytime soon, which means they probably haven't. They also have their Sprite stuff, which I've heard really good things about. It's meant to be VMs and sandboxes that you can safely run agents in that have their own primitives that will let them be powerful. And then there's a bunch of other random things that they've built that are just way cooler than what you can do on other clouds. I did a video a while back about Flame, which is an alternative way of doing serverless where you are encapsulating processes in your code base to spin them up on different servers for specific needs. Like if you **[24:16]** want to sometimes have a GPU for doing, I don't know, FFmpeg stuff, but you usually don't need it, having your stuff always run on the GPU box would be way too expensive if the GPU's not being used. But if you could have one function in your code base that runs on the GPU box and spins it up and handles it, then awesome. In this example, I'm sorry if you're not familiar with Elixir syntax, my beloved. You take this process that is defined here for generating thumbnails, which runs in FFmpeg, which could lock up the main server or just not be performed if it doesn't have a GPU, you can wrap it with a flame call, **[24:47]** exact same stub that function here, and it will return the result as though you just called this on the same box. It's so cool. It's just so far ahead of anything else I've seen for this type of stuff, but we need to be realistic. The negatives. The database reliability just isn't there. Even when I was doing my tutorials and work with them, I had my database just die and fail multiple times throughout. I learned to just not trust the database as many other Fly customers have. They often move their databases off of Fly to their own other alternative services like, you know, **[25:18]** PlanetScale. But, during dev it's so convenient. Like, the way that setting things up on Fly is so nice. It hurts, but the reality is that the database stuff isn't there. It in general, reliability just isn't quite where we need it to be. They had a huge outage recently. They likely will again in the future. They have built a lot of their own things, and a lot of those things are really, really cool. It's why they can do all this cool stuff, but it also means they're not as tried by the industry, and as a result, they're not as reliable. I also know with the DB thing, not managed. They don't do managed databases. They just give you an image that is running Postgres. **[25:51]** Apparently, they now do have managed databases. I did not know that. That's good to hear. But, uh last time I tried it, they didn't. That is a relief. I'm still going to say the reliability isn't good, but the fact they have managed DBs is a cool change. And I would also argue that within these options, Fly might be the highest risk of death. I would put them slightly higher than Digital Ocean in terms of this company might run out of money and die. I just have not seen a lot of big customers or revenue numbers or investments or any of the things that would make me confident Fly will still be here at the end of the year or even **[26:22]** early next year. Even when I was working with them, the rate at which the people I was talking to suddenly worked at the company anymore was a bit terrifying. I even went to ElixirConf 2024 and was sitting at a table with a bunch of Elixir nerds, including a few that worked at Fly, and watched as they checked their phones and got laid off. That does not inspire confidence. They also deprecate things, not a lot, but enough to be concerned. Somebody in chat just mentioned that they used to have a managed DB Superbase integration, but that got discontinued. Not the thing I would bet my whole business on right now, personally. One of the most fun **[26:52]** platforms I've ever built on, not confident that they will still be here next year. Take that as you will. And next we have Render, who has this big migrate from Heroku with near zero downtime banner on top. They know exactly what they're doing. Render is used by a ton of big companies. Their revenue is really solid. They've had no issues raising money. They understand modern tech and PHP. Even the founder of HashiCorp has had nice things to say about Render. Mitchell's a legend. Cool to see. They have a decent free tier. You have to immediately bump to their monthly tier **[27:23]** if you want to do more though. They don't have like boxes you're renting the same way. But they're pretty generous overall. Relatively modern, supports everything, generous free tier, likely staying around. They make enough revenue that I'm not worried about them disappearing anytime soon. Negatives, you pay a sub instead of server pricing. A lot of that pricing is hidden under the enterprise custom tier. They charge a separate monthly fee for setting up cron jobs. That's kind of funny. Oh, look at that. Their GitHub integration is still in a very good state. Last time **[27:53]** I used it it was pretty good, so that's good to hear. I'll put that in here. Good GitHub integration. Plus preview environments, which is not guaranteed across these different providers. Apparently the egress is super expensive as well. Definitely worth noting. Good call out, chat. The $20 tier comes with 500 gigs of bandwidth. 15 bucks per additional 100 gigs. Inbound bandwidth is free. Okay, that's cool. So uploading to it is free. Sending data from it costs money. That's actually a really nice call out. Good [ __ ] I would never fault anyone for going with Render. Seems like a really good option. Honestly, like one of the most reliable out of all of these. Like **[28:24]** I would say like other than AWS, least flight risk, too. But now we need to talk about Railway. Obviously, more than any point in here, account for bias here. Jake and I have a long history. I was almost hired as engineer number four at Railway all the way back in 2021. I've watched this company's ups and downs. I've used them for that entire five-year window. I love Railway to death. I have my issues with them. For the most part, it's a great platform. It's a phenomenal team and I'm very excited for them and all the success that they've been having. Benefits. Truly modern. It's just you'll feel the **[28:56]** difference when you use it. It just works great with everything. The CLI is awesome. The docs are awesome. The GitHub integration's great. It just behaves. It also is one of the best dashboards for actually seeing what's going on and how parts are linked. You can clearly see the different services, how they're linked to each other, the domain setup, all of that. Really good. There's availability is awesome, too. I haven't even bothered setting it up yet cuz this project hasn't needed it. The way they handle different environments is great. You can set up preview environments and things like that relatively well. It does not, as far as I know, have good automatic preview environment creation when you do PRs and **[29:27]** things like that. It might be able to be set up, but it's good. I honestly really like the way Adi put it here. Railway makes me smile every time I use it. The pricing's relatively transparent and clear. They drop hard numbers for what each thing costs. There's a little confusion around various different things like the relationship between like how these parts are measured. It's sometimes confusing to figure out what usage you're actually going to get. And then there are interesting things that are free that I'm not confident are going to stay free. So, like in the benefits section, egress from their **[29:57]** object store is free. But then in the negatives, object store is private only. You cannot do a public bucket. That burned me real bad on a project that I'm now migrating off of Railway storage. Free egress is a ticking timer in my opinion. No one offering egress for free can maintain that forever. Like there's always a catch. And I am a little scared of what that catch will be with Railway. This is the type of complaint that I might have for other things if I used them more, but as a pretty heavy Railway user, I see the flaws more. And the dashboard can get into some weird states, especially around DNS and SSL **[30:27]** stuff. You don't buy domains on Railway. I bought mine on Vercel, but then I set it up on Railway and SSL was broken forever. The dashboard just wouldn't verify the CNAME. It just It took a while to get that working and I didn't know if I was doing it right last time because the UI didn't really indicate what the current state was very well. Thankfully, I just left it alone for half an hour, went back and it was good. Not clear that was happening though or if it would or wouldn't work. Oh, and the egress does cost 5 cents per gig for services, but the object storage has free egress. But you are paying 1.5 **[30:58]** cents per gig per month for the storage. So, know that. I got the previous storage price from Jake. He might have just typo'd it, but 1.5 cents per gig is a pretty good price for the storage. I might rethink some things based on that. There's a lot more benefits to them though than we've gotten to here. Supports everything. Best DB setup I've ever had. Like the the way that you link services together and all of that is just so pleasant. Config is generally great. Perf is insane. They're rocking their own servers and they're good servers. I also think that the server farm I'm using for US West is pretty close to me which makes it feel just **[31:29]** absurdly fast. I'm just very happy with Railway. I'll call pricing fair overall. There are very few things on Railway where I'm like, "That's too expensive." And the one that I thought was, I was just wrong about. Oh, they do have previews and one-click rollbacks. That's good to know. The one-click rollbacks is huge and it saved me a ton of times. Depending on how you use the platform, it might even save you a shitload of money. Some customers who were on AWS before were able to cut their cost by 90% by moving to Railway and also get better experience. It's it's really good. I'm super happy with Railway. I bet you will be too. They are probably my top pick here. One last thing on **[31:59]** Railway before we get to EC2. They just raised $100 million. They're not going anywhere. They were already nearly profitable before. They might have actually been profitable for a bit. They are not going anywhere. AWS also never going anywhere. Super reliable. Like disgustingly reliable. Supported by everything. Great locations, so you know that they'll network with everything fast. Like every service tries to get themselves into AWS server farms so that you can have low latency with AWS EC2. The amount of integration that they have **[32:30]** with like everything is nuts cuz everyone's built it. Platforms like Terraform and Pulumi are largely built around EC2 and EKS and help Kubernetes is largely designed around how EKS works at this point. Like everything is building for EC2. Like if it doesn't support EC2, I am sus as hell. Guaranteed SLAs, reliability, all the things you need there. Fargate's dope. [snorts] There's tons of other services you can integrate alongside EC2 within AWS and externally that are insane. And most importantly, no one's ever been fired for picking AWS. It's the default and it's the default for a reason. It is **[33:02]** good. But there are negatives. Cost is surprisingly higher than competition. Their pricing is so annoying that usually you go use another service to look at it because it's just their pricing is God, they hide all this info so deep. Here we go. Sadly, this chart is doing hourly pricing, not monthly. Times 24 * 30. And there's a reason why. A 2 gig 1 vCPU box with just EBS storage is $22 a month. >> [sighs] >> If we're talking EKS, you're going to **[33:33]** want the beefiest nodes you can reasonably fit. So you can choose a 190 core Graviton box. Yeah, it's it's pretty nuts. AWS not only charges a significantly higher price than what I would expect for the tier of hardware, they don't really lower those prices. So it's kind of just like a fee you're paying forever on a box that's probably 6 plus years old and you're paying as though it's brand new. It's bad. It's crazy everybody always advertises like AWS is the cheap option. It's not. In many cases, Vercel is actually cheaper **[34:04]** than AWS. Just depends on how you're using them and if you're doing stupid things on either, you can screw yourself. It's no surprise Railway comes out cheaper as often as they do. So yeah, cost is not the thing you are saving. Setup isn't the thing you're saving either. You basically have to build a solution to handle your deployments on AWS. There have been multiple billion-plus dollar companies built just because setting up on AWS is too hard. Everything from Terraform to Vercel is arguably because AWS sucks to config. Dashboard is Cloudflare tier UX. **[34:35]** It at least works though. It's rare I'm on the AWS dashboard and things are just outright broken like they are on Cloudflare, but getting around it is hellish. Oh god, the permissions. I uh god, that's so many throwbacks. I I have been to hell with IAM. It's so bad. It's so [ __ ] bad. I I put this in the same bucket honestly as I put GCP and Azure now. If you're coming to me or a channel or video like this for advice on where to deploy, don't deploy to AWS. Seriously, don't. We've went over all of these options. You hopefully understand **[35:08]** what the values are for each of them. If I was to tier these, I'm going to ignore the ones I wouldn't recommend. I'll say top wrecks, the ones that I would absolutely recommend I think everyone should at least consider. Railway, Vercel, and Render. All easy S tier, you're good. I have a specific need tier, I would put Netlify if they have some specific integration or their queuing stuff works really well for you. Cloudflare, if you're willing to deal with the compromises around not having a proper node environment, very beneficial. Or you're just trying to micro-optimize for costs at crazy **[35:39]** scales, really good option as well. Maybe Hetzner. It hurts to put it here, but if your goal is to have the cheapest possible thing with insane free egress that's just hosted and you're okay with it being slow and unreliable, it can be fine. I wouldn't confidently tell you like, "Oh, go move that to Hetzner." but it is an option worth considering. Oh, and Fly. Absolutely fly.io. While it might not still exist in a year or two, it has some really compelling offerings that nothing else does. There's a good chance you run into a problem Fly uniquely solves, worth considering if you do. And then I have the you won't **[36:10]** listen anyways tier. This is for people who watch these videos for fun, but can't realistically take my recommendations for all sorts of different reasons. This is where I put most of the AWS offerings like Lambda and EC2. I'd also put GCP in here, Azure, IBM Cloud, things like that. Like if your employer already chose it for you, it's fine. And pretty much everything else, I don't think I can recommend it now. If you pick anything here, you're probably well set. If you pick anything **[36:41]** here, I hope you have a good reason. If you pick anything here, I hope it was your boss that picked it, not you. Now you know how I think about these things, and hopefully you can now better understand why almost everything I deploy is on Vercel and Railway, and maybe in the future Render as well. Yeah. And we barely even talked about CDNs. What a video. I hope this helps you better understand what these platforms are, what benefits and negatives each have, and maybe just maybe you'll have more confidence when you pick the next place you host. Let me know how y'all feel, and until next time, please stop flaming me about Hetzner. I **[37:11]** really don't care about your $5 VPS.