[HN Gopher] We moved Railway's frontend off Next.js. Builds went...
___________________________________________________________________
We moved Railway's frontend off Next.js. Builds went from 10+ mins
to under 2
Author : bundie
Score : 163 points
Date : 2026-04-08 06:01 UTC (17 hours ago)
(HTM) web link (blog.railway.com)
(TXT) w3m dump (blog.railway.com)
| mellosouls wrote:
| Reminder, as its not mentioned:
|
| Next.js is produced by Vercel, a competitor to Railway.
| debarshri wrote:
| Moving to vite + tanstack builds faster is also a fact.
| pjmlp wrote:
| Only if they weren't using Turbopack.
| lukasholzer wrote:
| does turbopack make such a difference on next.js sites?
| pjmlp wrote:
| Yes, because it is yet another Typescript and Webpack
| like compiler written in Rust.
|
| Note how many HNers are making the same remark.
| abustamam wrote:
| It's not mentioned because it's not relevant.
| mellosouls wrote:
| Of course it should be mentioned, it's a basic disclaimer.
| norman784 wrote:
| I don't know the situation now, but a while ago there were a
| lot of pushback using Next.js because it was not easy to use
| all features if not hosted on Vercel.
| abustamam wrote:
| We used NextJS on a project hosted on AWS a while ago. We
| learned quickly it wasn't the best tool for what we wanted
| to do which is why we stopped using it. But it's an open
| source project whose purpose is to drive devs to Vercel. It
| doesn't surprise me that there are some features that work
| best with Vercel (but it does surprise me that only
| recently other providers started to need adapters).
|
| Anyway, my point is that no one is forced to use NextJS and
| if they like NextJS but not Vercel they can always fork it
| or, apparently write an adapter.
| pjmlp wrote:
| Besides the way it maps server side code into serverless,
| it has a custom runtime, functions that expose cloud
| infrastructure, integration with multiple language
| runtimes for the backend.
|
| You get to pick Vercel + headless CMS + assets managed +
| eshop, and you're done in terms of big corporations.
|
| Might seem a lot in licenses, however it allows for
| smaller dev teams, which is what management floor cares
| about, all those salaries.
| cryptonym wrote:
| True. That framework is owned by a cloud company and the way
| they host Next.js apps in a secure and scalable way remains
| secret sauce.
|
| Now it doesn't really impact build time and Railway offers
| Next.js hosting.
| maccard wrote:
| It's absolutely mind boggling to me that we have gotten to a
| point that building a web frontend takes longer than compiling
| the Linux kernel..
| Hamuko wrote:
| As a non-frontend developer mainly observing and touching
| something here and there, a lot of the things that frontend
| developers do seem vastly over-engineered.
| ramon156 wrote:
| I'm not insanely deep into frontend, I mostly just pick up
| React and call it a day, but it seems like this is also over-
| engineered?
|
| I've seen vanilla JS before, and I just know I wouldn't want
| to do the housekeeping that comes with it. People claim it's
| less work because it' simpler, but I fully expect myself to
| rewrite the thing at least twice, only to give up because I
| have no actual mental model anymore of how it works.
| selfmodruntime wrote:
| I have never in my career encountered a Vanilla JS project
| of at least medium size that I would have called simple.
| They all feature brittle selfmade frameworks whose
| developers have since left the company years ago.
| maccard wrote:
| I write C++ and C# all day - I think it's fair to say the
| same about a project in any programming language!
| thibran wrote:
| Isn't the main problem that the building blocks the modern
| web is based on are not a good fit for what we do with it?
|
| CSS is a total mess. HTML is a mess. JS is okay, but is not a
| high quality language.
|
| We would save so much time and money if we would have a
| modern base to build on. Sadly this will probably never
| happen, because company interests will try to corrupt the
| process and therefore destroy it.
| selfmodruntime wrote:
| How are CSS and HTML a mess? Combined, they're an
| incredibly powerful layout engine that works almost the
| same across all environments and devices while also
| featuring easy accessibility.
| rk06 wrote:
| the biggest problem with html/css is that they are
| tightly coupled. you can't meaningfully modify a layout
| with css alone.
|
| second biggest problem is "no stricter mode". so even
| wrong or useless html/css code goes unflagged and is
| treated as it is normal.
|
| CSS is way too powerful.
| rho138 wrote:
| > you can't meaningfully modify a layout with css alone
| Wut?
| manuelmoreale wrote:
| > you can't meaningfully modify a layout with css alone.
|
| https://csszengarden.com/pages/alldesigns/
|
| That statement wasn't true ages ago, and it's even less
| true now.
| thibran wrote:
| When taking a bird eyes view on CSS it will be hard to
| oversee that CSS is a mixture of different concepts that
| evolved over time with a lot of inconsistentsies. It is
| possible to make it work, but it's not pretty.
|
| Same for HTML. If the web would be reimagined today,
| there is a very low chance that we would create HTML as
| is.
| nixpulvis wrote:
| Same reason why 90% of websites have serious UX issues and
| constant bugs. This and ad frameworks.
| itopaloglu83 wrote:
| It's mind blowing when you check the generated code, because
| it goes over 50 elements deep for a simple looking website.
|
| Makes me think that there's no way this is computationally
| efficient either.
| crooked-v wrote:
| That particular issue is nothing to do with Next or React
| and everything to do with how HTML/CSS is a really shitty
| layout engine.
| maccard wrote:
| Hard disagree. This is JavaScript frameworks building a
| hierarchy for themselves and ignoring any sort of
| complexity on the generated DOM. There's 0 reason for
| these 8-10 nested divs other than that's what the
| framework spits out.
| maccard wrote:
| This is my understanding too - tools like react are like
| microservices - they're a technical solution to an
| organisational problem. HTML/css/JavaScript is an imperfect
| abstraction, so we got bootstrap. Then we got client side
| frameworks which introduced a build step, and then we got
| asset bundles, optimisers, linters, validators, tree shakers,
| package managers, validators for your package managers. All
| of these monkey patched around the actual problem with more
| abstractions, and the end result is what we have now.
| pjmlp wrote:
| Like using SPAs for classical Web development, and then they
| rediscover PHP.
| rafaelmn wrote:
| And underenginered at the same time !
| mmarian wrote:
| Not that backend is any better - microservices everywhere,
| must scale to Facebook traffic even if we only have 10
| customers, etc. Saying this as a backend dev
| selfmodruntime wrote:
| C is infinitely less complex to parse and validate than
| Typescript. C is compiled in a single pass, the `tsc` type
| checking algorithm has to check structural typing, conditional
| types and deep generics while _also_ emulating JS ' dynamic
| behaviour.
| iptq wrote:
| I don't think any C compiler has been single pass for the
| last 20 years. Typescript's analyses are also not that
| complicated, it's just that the typescript type checker is
| written in js. Iirc the actual ts -> js part is pretty fast
| with some of the more recent compilers.
| maccard wrote:
| I disagree - this is an excuse. Even the post we're
| commenting in now shows that it's a series of poor
| abstractions and bad tooling that takes way too long to do
| the basics, combined with a language and ecosystem that
| encourages this behaviour . They saw a 5x speed up by
| changing tools while still using a JavaScript framework so
| it's clearly possible for it to not be complete nonsense.
| HeavyStorm wrote:
| That's not the point...
| nicoburns wrote:
| It's mostly because a lot of the web tooling is written in
| JavaScript. The build times for the "next generation" tools
| written in Rust/Go are dramatically faster.
| jspaetzel wrote:
| Incredible that the builds were ever 10min. How far things have
| regressed.
| mlnj wrote:
| This is one of the most frustrating thing about working with
| NextJS. There seems to be no way to improve the speed of building
| the app.
| abustamam wrote:
| I've used the other major meta frameworks (remix and tanstack).
| I don't think there is a way to improve the speed of building
| the app in those ecosystems. Happy to be proven wrong.
| nulltrace wrote:
| Could be the bundler re-resolving the whole dependency graph on
| every build, even when nothing changed.
| tgdn wrote:
| We went through a very similar migration. Had a Next.js landing
| page and a separate TanStack Router SPA - consolidated both into
| a single Vite + TanStack Start app. Same experience with build
| times and the architecture mismatch: our app is heavily client-
| side with real-time state, and fighting Next.js's server-first
| assumptions wasn't worth it. TanStack Router's type-safe routing
| and file-based route generation have been great.
| SilverSlash wrote:
| I hadn't heard of TanStack but a quick look at their website
| doesn't inspire confidence tbh. I mean, just take "TanStack
| Pacer".
|
| It provides such things as:
|
| ```
|
| import { Debouncer } from '@tanstack/pacer' // class
|
| const debouncer = new Debouncer(fn, options)
|
| debouncer.maybeExecute(args) // execute the debounced function
|
| debouncer.cancel() // cancel the debounced function
|
| debouncer.flush() // flush the debounced function
|
| ```
|
| Why? Just why do you need to install some "framwork" for
| implement debouncing? Isn't this sort of absurdism the reason
| why the node ecosystem is so insecure and vulnerable in the
| first place? Just write a simple debouncer using vanilla js...
| MajimasEyepatch wrote:
| Obviously it's more than just debouncing.
| https://tanstack.com/pacer/latest/docs/overview
| tacker2000 wrote:
| TanStack started out by providing a very good JS table
| library. Now they offer a Router, and some more libs. They
| are definitely an up and coming name in the JS space.
| chrisweekly wrote:
| That's... not quite right.
|
| [EDIT] I typed "Router" when I meant "Query".
|
| TanStack _Query_ is the relatively newer name for React
| _Query_ -- one of the most popular JS libraries of all
| time.
|
| TanStack Start is a recent metaframework (and the one w/
| the brightest future, IMO), but Tanner and team have
| profoundly significant bona fides. IOW, the dev team is far
| from being the "new kids on the block".
| SahAssar wrote:
| Do you have a source for TanStack Router being a newer
| name for React Router? Doesn't seem like it when looking
| at the sites for both projects.
|
| Are you thinking of the whole Remix/ReactRouter thing?
| chrisweekly wrote:
| (facepalm)
|
| Thank you, but no. I typed "Router" when I meant "Query".
| TanStack Query is the newer name for the library FKA
| react-query.
|
| TanStack Router is an alternative to React Router.
|
| TanStack Start is an alternative to Remix/react-
| router-7's framework mode.
|
| The naming history and evolution of react-router and its
| relationship to Remix is a bit convoluted, but an
| unrelated tangent to the point I was making.
| tacker2000 wrote:
| That's... not quite right :)
|
| React Router, which belongs to Remix, which was acquired
| by Shopify, is here: https://github.com/remix-run/react-
| router
|
| Tanstack Router is an entirely new router.
| chrisweekly wrote:
| Thanks yes I know, I typed "Router" meaning "Query",
| noted in a peer comment. sigh.
| chrisweekly wrote:
| Not to feed the trolls, but you responded to a comment about
| TanStack Start (a full-stack metaframework) by denigrating
| @tanstack/pacer -- a separate, niche utility published by the
| same team.
|
| You're entitled to your opinions, but I'm happy to defend the
| rationale of leveraging battle-hardened, rigorously-tested,
| open-source, type-safe libraries instead of DIY cowboy
| vanilla js spaghetti.
| UserMark wrote:
| I have a Nextjs heavy app which takes around 7 minutes currently.
| But I've been thinking of moving away from next for a long time
| now. TanStack seems to be a good fit. This gives me a bit more
| confidence in just doing it.
| Kelteseth wrote:
| As a cpp developer I had to chuckle there. And I thought our
| compile times were bad.
| abustamam wrote:
| I've been pretty happy with TanStack start for a medium-sized
| project. I would not know how its build time would compare to
| Next, but our similarly sized Remix (sorry, React router v7)
| app takes longer to build.
|
| TanStack just has a nicer mental model overall and works great
| with TanStack query for cache I validation and stuff like that.
|
| Remix was promising but there was so much ceremony in
| registering API routes and stuff. Tanstack just lets you define
| server functions arbitrarily with no ceremony.
|
| Might be worth a spike and some tokens to ask Claude Code to
| migrate and test the build time and ergonomics.
| UserMark wrote:
| I've been on the remix on a previous project, I have to say
| that Remix was even worse. But that's probably of the setup
| with vite etc not being correctly done.
| cryptonym wrote:
| Is server-rendered HTML that bad for 2026 web or is everyone
| building complex apps?
|
| Many of my customers insists on using Next.js or similar but
| when I browse their website I don't get the point. They are
| downloading and executing megabytes of JS while in-page
| interactions tends to be limited to few basic stuff. Never seen
| one of their project requiring offline mode. Maybe that's being
| able to easily replace a [FRAMEWORK] dev with another.
| sosodev wrote:
| I think the unfortunate truth is the simplest. Web
| development has long been detached from rationality. People
| are drawn to complexity like moths to a flame.
| mschuster91 wrote:
| > People are drawn to complexity like moths to a flame.
|
| Not to complexity, but to abstraction. The more something
| is abstracted away, the more fungible "developers" become,
| to the eventual tune of Claude Code.
|
| No one cares that trying to debug a modern application is
| as hellish as its performance, the KPI that executives go
| for is employment budget.
| sosodev wrote:
| I don't know if Next.js, TanStack, etc are more abstract
| than Rails, Django, etc. They're undoubtedly more complex
| though. I also find it hard to believe that it's some
| sort of conspiracy by management to make developers more
| fungible. I've seen plenty of developers choose
| complexity with no outside pressure.
| pjmlp wrote:
| It is fashionable, and Vercel has made a chain of partners
| that make Next.js/React the only official option to extend
| SaaS products.
| wilson090 wrote:
| Are you on turbopack? It's available on Next 16 and just took
| our build times down from 6 minutes to 2 minutes
| cbovis wrote:
| Yep this is what's often misunderstood.
|
| We also recently cut our build times in half moving from
| Webpack to Turbopack on production builds after jumping to
| NextJS 16. We'd already been using Turbopack in development
| for a while which yielded massive DX improvements related to
| performance. Production build times will drop further once
| Turbopack production build caching is stable.
|
| Webpack -> Turbopack is the smart initial migration. I'd bet
| Railway went straight from Webpack -> Vite not realising that
| their real gains sat with the build tooling, not NextJS vs
| Tanstack.
| UserMark wrote:
| Yes I'm on turbopack and running the latest version of
| Nextjs.
| nomel wrote:
| I made two serious attempts to get into front end web
| development, around 5 years apart. Both times I started with
| the most popular framework. Both times the most popular
| framework was something different before I even finished the
| project.
|
| Looks like maybe things haven't changed much?
| Eric_WVGG wrote:
| I recently switched from NextJS -- where every one of the
| dozens of projects I built would have 7-8 minute deployment
| times, regardless of hosts -- to React Router, and saw my
| deployment times drop to 1-2 minutes.
|
| Aside from some difficulty with mastering environment
| variables, I've been delighted with the change and will
| probably not look back.
| samwreww wrote:
| They don't even mention the Next.js version used - where they
| using Turbopack or not?
| wilson090 wrote:
| excellent question - recently switched from turbopack after
| getting annoyed by build times. we saw them go from 6 mins to 2
| mins
| huksley wrote:
| Anyone tried to use vinext from Cloudflare in production? Might
| be faster.
|
| But seriously, not sure why NextJS builds take so much, we are
| using stable and functional pages router in DollarDeploy and it
| is still takes too much time to build.
| wouldbecouldbe wrote:
| The irony is deploying NextJS on the railway platform is super
| slow since they use containers, on Vercel 2 min is like 12 min on
| railway, deployments on a vps are only like 20 seconds.
|
| *I know this is just build time, so this is different then their
| deployement time
| huksley wrote:
| Not containers to blame but overprovisioning and how much
| resources dedicated to building. I am not sure how Vercel gets
| things build in literal seconds, but, hey, they are the
| creators of NextJS.
|
| At DollarDeploy we building it also in containers but every
| build get 4GB/2CPU so it is quite fast but not as fast as
| Vercel.
| pjmlp wrote:
| Turbopack, custom runtime infrastructure on top of AWS
| Lambda.
| mememememememo wrote:
| Wait till you use HTMX!
| SilverSlash wrote:
| As in, htmx is better? I haven't used it but last I looked into
| it I was extremely confused as to whether it was a meme, an
| actual framework, or both.
| mememememememo wrote:
| None of the above. It is a utility (I guess framework maybe)
| for a feature that was cool in ASP.NET back in 2005. But that
| is it's charm. It is just JS swapping out the dom for you.
| recursive wrote:
| Not sure what you're thinking of, but the first release of
| HTMX was 2020. Its predecessor, intercooler, was first
| released in 2013.
| 0x457 wrote:
| HTMX is great when your web interface is just a
| representation of a server state.
|
| If web interface is an application backed by a remote state
| HTMX falls apart.
| nchmy wrote:
| can you give an example?
| nchmy wrote:
| Wait till you use Datastar!
| Hendrikto wrote:
| Two minutes is still way too long. What are we doing? This is
| ridiculous.
| selfmodruntime wrote:
| We're doing structural type checking for a language that wasn't
| developed with that in mind.
| rishabhparikh wrote:
| 2 mins for a production deploy of an app with millions of
| users? Seems fine to me! How fast would you expect it to be?
| BoredPositron wrote:
| How does an apps user base affect its build time?
| jasonlotito wrote:
| Not the op and I get your point, however...
|
| One way to think about it might be that the site supports
| lots of users who use it for various things. So, everyone
| uses 80% of the site, but everyone also uses a different
| portion of the final 20%. So, if you have lots of users,
| you might also have lots of smaller features that a
| significant minority use.
|
| I don't know, just an interesting way of thinking about it.
| mbesto wrote:
| It's a proxy for complexity.
| bdangubic wrote:
| so build time scales with the number of users? meta's build
| times of roughly 2hrs and 11 minutes then makes a lot of
| sense
| fnoef wrote:
| :suprised_pikachu_face:
|
| Is the quality of software engineers really dropped that low that
| people get excited when they move off from "heavy bloated"
| frameworks to lighter alternatives? Or is this just SEO farming
| garbage to position the company higher in search results?
| yla92 wrote:
| Both can be true at the same time!
| SilverSlash wrote:
| A lot of the LLMs are very familiar with next.js and vercel is
| also aggressively building an ecosystem around their tooling for
| LLMs. So I wonder if this problem will only be exacerbated when
| everyone using LLMs is strongly nudged (forced) to use next?
| ai_slop_hater wrote:
| When you create a Next.js project from Vercel's template, you
| get an AGENTS.md that literally says "THIS IS NOT THE NEXT.JS
| YOU KNOW"
| mcintyre1994 wrote:
| Is that because LLMs default to the older pages router? Or
| are they actually providing a different version of the
| library optimised in some way for agents?
| ai_slop_hater wrote:
| I think they just want LLMs to read the docs they began
| shipping[0] along with the library instead of using their
| own knowledge. For example, when I used Next.js a few
| months ago, models kept using cookies() and headers()
| without await, because that's how older Next.js versions
| worked, but modern Next.js requires await. I imagine there
| are more cases like this.
|
| [0]: https://nextjs.org/docs/app/guides/ai-agents#how-it-
| works
| HKayn wrote:
| One rather prominent case would be Tailwind. v4 made
| breaking changes in the way Tailwind is set up, requiring
| different packages and syntax. However, if you ask an LLM
| how to set up Tailwind on your Vite & React app, it will
| confidently list the setup steps for Tailwind v3, which
| no longer work.
|
| At times I would see people daily asking for help with
| their broken Tailwind setups, and almost always it was
| them trying to use Tailwind v4 the v3 way because some AI
| told them so.
| lovehashbrowns wrote:
| This was so unbelievably obnoxious when I first started
| trying to use Cursor last year at some point. Also
| because if you tried to not use tailwind the AI would
| eventually try to force it in anyway. I don't know how it
| is nowadays but that was so frustrating and funny at the
| same time. And! When I setup Tailwind v4 ahead of time,
| got it working, and told the AI about the v4 changes, it
| would "correct" it to v3 anyway. Another fun "metric" was
| to ask an AI how to setup react because it was still
| recommending create-react-app though nowadays I'm sure
| it'll be harder to find any model that still has that in
| its training set.
| GrayShade wrote:
| We've had shitty bloated websites before LLMs were a thing.
| miyuru wrote:
| I just tried their domains page it took 10.8MB of data and took
| 2s for the DOM to be ready.
|
| page actually took 17s to fully render with multiple shift
| changes.
|
| all to render a domain search bar similar to google home page.
|
| https://railway.com/domains
| anematode wrote:
| Dear lord. It's actually laggy for me to scroll on that page.
| hazelnut wrote:
| same here and I'm using a beefy MacBook (Apple M4 Max, 64gb
| ram). something is wrong with the front end code. there are a
| lot of animations, so my hunch would be that something goes
| wrong there.
| anematode wrote:
| Moore said computers get twice as fast every 18 months. Web
| devs took that as a challenge.
| OJFord wrote:
| He said transistor count on chip doubles. (The more
| accurate pithy comment would be they took it as available
| resources.)
| anematode wrote:
| U+1F913
| petcat wrote:
| web dev is a sewer
|
| All my projects are server rendered with jinja/minijinja,
| bootstrap, jQuery, and htmx when I need a little bit of SPA
| behavior on forms.
|
| No builds, just static <script src= tags. Very fast and easy.
| I'll never recommend anything else.
| giancarlostoro wrote:
| With C#'s Blazor templating, you can ditch all JS logic, and
| use raw C# for all front-end logic, and have it all be
| transparently server rendered similar to how Phoenix has
| LiveView.
|
| I also have experimented with HTMX and Django, and that seems
| to be a nice combination.
|
| Everything is AJAX again.
| CharlieDigital wrote:
| I've a C# fanboy, but Blazor's DX just isn't very good
| compared to say Vite.
|
| There are many conditions under which the hot reload just
| straight up crashes out regularly.
| giancarlostoro wrote:
| Hot reload definitely needs to grow.
| nicksergeant wrote:
| I'm coming back to Django after a decade of experience with
| it post-0.96 and having moved to Next.js a few years ago.
| Going from 1,700 dependencies to 65 total with Django +
| Wagtail + HTMX.
| pjmlp wrote:
| When I am given the choice to pick a stack, it is classical
| Java and .NET Web frameworks, with minimal JavaScript.
|
| On hobby projects same script approach without any kind of
| build step.
| bastardoperator wrote:
| Sounds more difficult then modern web frameworks. We've all
| done this for little projects, but anything with users or
| development teams, your method is DOA.
| array_key_first wrote:
| I disagree, most webapps, like 99.9% I would say, are just
| forms, links, and pages. Meaning, they can be done with 0
| reactivity and that is the most simple and straightforward
| way to do it.
|
| Less code is basically always better, so if you can skip
| the huge amounts of JS and orchestration required by modern
| web frameworks, then it will be easy. People are out here
| using React to render static pages. It's very overkill.
| gib444 wrote:
| The 3.57MB background PNG is hilarious [0]
|
| [0] https://railway.com/dots-oxipng.png
| rubyn00bie wrote:
| Ha! I normally wouldn't find it quite so hilarious, but it's
| a stylistically pixelated image. There's just too much irony
| packed in there to not chuckle.
| c-hendricks wrote:
| It's more halftone (might not be the correct term), not
| pixelated
|
| There might be more irony in saying it's stylized pixels
| without realizing that the style of the image can't be
| replicated with blocks of the same size but I dunno, I'm
| not Alanis Morissette
| picardo wrote:
| They could have saved themselves 3MB by converting it to
| AVIF.
| allthatineed wrote:
| I got it down to 1.03MB by just switching the png to palette
| encoding mode.
| toddmorey wrote:
| There are some easy optimizations wins for this page but none
| of the top ones are framework related. Maybe with the faster
| build times they can easily optimize images and 3rd party
| dependencies. As someone else pointed out, nearly half that
| data is unoptimized images.
|
| For the curious, google's current homepage is a 200kb payload
| all in, or about 50 times smaller.
| mattmanser wrote:
| Who remembers sprite sheets? Does that give my age away?
|
| I did an optimization pass for a client once where I got rid
| of a ton of the sprites but didn't have the energy to redo it
| all, so it just had huge sections that were blank.
|
| Super snappy loading afterwards though.
| ricardobeat wrote:
| Yes, good times! With http2/3 they don't really matter
| anymore though, you get similar benefits from request
| pipelining.
| chrisweekly wrote:
| Spriting is actually harmful for performance except in
| specific HTTP-1 scenarios.
| l5870uoo9y wrote:
| I migrated the landing pages for my app[1] from Nextjs to Astrojs
| mainly because I was paying Vercel $20 per month for serving
| static pages(it's 4 times more than I pay Railway for the
| Postgres database for the actual app and also 4 times more than I
| pay Cloudflare for hosting all my apps). I used AI for migrating
| and it took a few days only as the existing repo was used as
| "instructions" and it included some upgrades and improvements
| here and there.
|
| [1]: https://www.sqlai.ai/
| christoff12 wrote:
| this is neat
| xandrius wrote:
| Why is everyone so afraid to get a $5/mo Ubuntu/Debian VPS,
| install nginx and call it a day?
|
| Then you can even run multiple projects off the same server.
| kami23 wrote:
| I just did this over at Hetzner and Claude admins it for me
| so I don't need to learn the CLI or anything, describe the
| proxying I want, and it setups up a bunch of small side
| project pages for me.
| xandrius wrote:
| For me I always default to UpCloud, great team and great
| services. From Finland!
| kamikazeturtles wrote:
| How do you use Claude to admin it? Does Claude SSH into the
| server and do everything or just write bash scripts?
| skydhash wrote:
| No click-ops that way.
| kennu wrote:
| It means you take responsibility of maintaining the server
| forever, i.e. dealing with TLS certificates, SSH keys,
| security updates, OS/package updates, monitoring, reboots
| when stuck, redeploy when VPS retired, etc. Usually things
| work fine for a year or two and then stuff starts to get old
| and need attention and eat your time.
| shimman wrote:
| This is extremely easy with tools like dokploy tho... I use
| dokploy locally to manage all my VPSs + home server. Truly
| good stuff and I don't believe your quip at the end, it
| feels like poisoning the open source waters for
| consolidated anti democratic cloud platforms.
|
| It's way way way way easier managing a basic VPS that can
| be highly performant for your needs. If this was 2010, I'd
| agree with you but tooling and practices have gotten so
| much better over the last decade (especially the last 5
| years).
| kennu wrote:
| Maybe you're right - I've never tried dokploy, but from
| documentation it sounds like mostly a deployment,
| monitoring and alerting tool. For me the problem has
| always been that once you get the alert (or something
| just stops working), a human needs to react to it and
| make things work again. In cloud services you mostly pay
| for them providing the human, and in self-hosting you're
| the human.
|
| I can see though that today's AI models could eventually
| replace the human in the loop and truly automatically fix
| every possible situation.
| c-hendricks wrote:
| I must be using the wrong cloud services. Whenever a part
| of our app goes down someone on the team still needs to
| respond to it.
| bdangubic wrote:
| you actually need new ops teammates, not new cloud
| services :)
| kennu wrote:
| You might be right. I've been mostly using serverless /
| managed cloud services such as AWS Lambda, API Gateway,
| S3, DynamoDB for the past 10+ years. When I've needed to
| respond, it's been because I myself deployed a bad update
| and needed to roll it back, or a third party integration
| broke. The cloud platform itself has been very stable,
| and during the couple of bigger incidents that have
| happened, I've just waited for AWS to fix it and for
| things to start working again.
| wouldbecouldbe wrote:
| yeah i've had more downtime on managed db's & cloud
| servers then on my own managed VPS. And if it happens,
| with VPS i can normally fix it instantly compared to
| waiting 20-60 min for a response, just to let you know
| they start fixing it. And when they fix it, it doesnt
| always mean your instance automatically works.
| satvikpendem wrote:
| Agreed, Dokploy is great, not sure why you got downvoted
| for the suggestion.
| SoftTalker wrote:
| vs. trusting someone else to do all that for you, and do
| you then verify that it gets done properly?
| kennu wrote:
| When buying the infrastructure as a managed cloud
| service, yes, I trust that they've got people handling it
| better than I could myself. The value proposition is that
| I don't even see the underlying infrastructure below a
| certain level, and they take care of it.
| fnoef wrote:
| Oh no! Issuing SSL certificates! The horror!
|
| I really doubt that people who can't install an ssh key
| should be able to practice software engineering. Sometimes,
| I think that software engineering should be a protected
| profession like other types of engineering. At least it
| will filter out the people who can't keep their OS up to
| date.
| asadm wrote:
| Time is a precious (and really expensive for SWEs)
| resource, why should one spend it on updating certs and
| instances?
| satvikpendem wrote:
| They shouldn't, that's why self hosted PaaS already do it
| for you, it's not a differential reason to use cloud
| services instead just because they do it for you too.
| kennu wrote:
| This is not about how easy or difficult it is to issue
| TLS certificates, to configure SSH keys or to update the
| OS. It's about having to actively maintain them yourself
| in every possible situation until eternity, like when TLS
| versions are deprecated, SSH key algorithms are quantum-
| hacked, backward-incompatible new OS LTS versions are
| released, and so on. You will always have new stuff come
| up that you need to take care of.
| cosmic_cheese wrote:
| Exactly. Also, being that my specialty is writing
| software and not server maintenance, no matter how much
| of an effort I put forth there's substantial risk of
| blind spots where holes can lurk.
|
| I felt more comfortable maintaining a VPS back between
| 2005 and 2015, but at that point attackers were
| dramatically less sophisticated and numerous and I was a
| lot more overconfident/naive. At least for solo
| operations I'm now inclined to use a PaaS... the
| exception to that is if said operation is my full time
| job (giving me ample time to make sure all bases are
| covered for keeping the VPS secure) _or_ it 's grown
| enough that I can justify hiring somebody to tend to it.
| nchmy wrote:
| Caddy server even does ssl for you automatically.
| ipsento606 wrote:
| certbot and ssh keys are things you set up once
|
| I haven't rebooted my DO droplets in something like 5
| years. I don't monitor anything. None of them have been
| "retired".
| wouldbecouldbe wrote:
| just ask claude to do all that :), he is excellent and
| installing & managing new servers and making sure all
| security patches are updated. Just be careful if its a high
| risk project.
| mbesto wrote:
| Or a homelab using Proxmox or Unraid.
| sanghyunp wrote:
| The two-PR strategy is smart -- decouple from the framework
| first, then swap it. That's the kind of migration discipline most
| teams skip, and it's why they end up running two systems in
| parallel for months.
|
| I run a Next.js App Router site in production (marketing + blog).
| Build times aren't painful yet, but I've noticed the same
| pattern: most of the build time is Next.js doing things I didn't
| ask for. For a mostly-static marketing site it's tolerable, but I
| can see how it becomes a dealbreaker for a rich client-side app
| like Railway's dashboard.
|
| Curious -- after the migration, did you see any measurable
| difference in runtime performance (TTFB, hydration) or was the
| win purely on the build/DX side?
| oefrha wrote:
| Time to move your blog off Next too? It's slow as molasses for
| me, loads a billion JS chunks and JSON fragments, when it can be
| a static site.
| eino wrote:
| We made a similar move from Next.js to Vite (with Tanstack
| router): CI build dropped from 12 min to barely 2 min. We won't
| look back.
| pjmlp wrote:
| Zero references to Turbopack, maybe start there?
| lukasholzer wrote:
| This is the kind of post I wish more teams would write. The "we
| picked the popular thing and it got slow" story is so common. But
| most teams just live with it. They don't want to touch it. 10
| minutes to 2 minutes is huge for dev speed!
|
| I'm a huge fan of tanstack start especially the ability to just
| static prerender some paths (a feature I'm missing a ton with
| astro) For me tanstack start is the new dominator on the stack!
| sakopov wrote:
| Can we just get back to html/jQuery/handlebars? Those were the
| good old days :`(
| nchmy wrote:
| Nothing stopping you. Check out datastar instead though.
| ceritium wrote:
| Railway should try Rails
| dmix wrote:
| You can't keep JS devs away from the new shiny framework for
| long.
| butz wrote:
| Now try to do the same thing that MDN did to their website and
| reduce 2 minute build times to 2 seconds.
___________________________________________________________________
(page generated 2026-04-08 23:01 UTC)