justjake

6 ms·

1.
by justjake 6mo ago
Appreciate the feedback. We got some feedback previously that things were "too technical" and not acknowledging it from the what users saw. I've gone ahead and re-added the surrogate keys statement to the press release. Thank
2.
by justjake 6mo ago
We indeed run tests as well as stage releases. For this issue, when rubber met road in production, we saw cases which weren't visible in staging. We've rolled out some changes (detailed in the blogpost) which should avoid this in
3.
by justjake 6mo ago
> Honestly for a production-grade _platform_ company, that also does compliance (SOC2/3, HIPAA etc.), not having a staged release is negligent, and how you guys are handling this is a huge red flag. I've done such changes mysel
4.
by justjake 6mo ago
Railway founder here, providing some color > Why were they making CDN changes in prod? With their 100M funding recently they could afford a separate env to test CDN changes. Did their engineering team even properly understand surrogate k
5.
by justjake 6mo ago
Would you mind pointing out these claims? Happy to address them personally
6.
by justjake 6mo ago
Fixed the typo in that second paragraph and aligned the section on the Set-Cookie stuff. Anything else that can be made more clear?
7.
by justjake 7mo ago
Totally! People who see the impact will likely see more impacted than say, 3% of their services. Not all disruption created equal. We rolled out a change to update our fraud model, and that uses workload fingerprinting Since, in all likelyh
8.
by justjake 7mo ago
Railway founder here. <3%. That said, we treat this exigently seriously! Any downtime is unacceptable and we'll have a post mortem up in the next couple hours
9.
by justjake 7mo ago
Hello! Railway founder here We'll have a post mortem for this one as we always write post mortems for anything that affects users Our initial investigation reveals this affects <3% of instances Apologies from myself + the Team. Any
10.
by justjake 9mo ago
Jake from Railway here > And my hosting provider is saying, "you are not allowed to push out your urgent fix, because we see that your app contains a far less urgent problem." There is no button that says "I understand, pr
11.
by justjake 1y ago
Bingo. Nix doesn't give you a generalizable-across-languages-and-ecosystems way of specifying specific versions without blowing up your package size, unless you hand Nix to your users (which we didn't want to do) Maybe we were hol
12.
by justjake 2y ago
Hey y'all! 3 years ago we built Nixpacks. However, we ran into some pretty large pains using Nix for dependency resolution So today we're rolling out Railpack, the successor. It results in: - Up to 75% smaller images - Up to 5x fa
13.
Show HN: Railpack – Zero-Config Dockerimage Builds(github.com)
6 points by justjake 2y ago|2 comments
14.
by justjake 2y ago
We're actually profitable on this round of funding. We've venture backed, but we also wanna make sure people know we're here for the long haul.
15.
by justjake 2y ago
Author here. We've talked previously about our datacenter buildout ( https://blog.railway.com/p/data-center-build-part-one ) This is the "next step". We're using our baremetal presence to now undercut
16.
You can't build a cloud on a cloud(blog.railway.com)
11 points by justjake 2y ago|3 comments
17.
by justjake 2y ago
We use ~~arch~~ nix BTW I think, least for us, this is tablestakes stuff. You should be able to get the repo going day 1 and get a commit in But there's just a fuckload of context beyond the code. You can get it from the RFCs we write
18.
by justjake 2y ago
Happy to answer any questions. This all seems very obvious in retrospect, but I wanted to share for any other early stage companies in the hopes people can avoid some scaling pains!
19.
We learned to stop sucking at onboarding(blog.railway.com)
4 points by justjake 2y ago|3 comments
20.
by justjake 2y ago
That $0.10 per GB is direct pass along for the cloud ingress fees We can lower that once we’re fully on metal
21.
by justjake 2y ago
FWIW this is the advantage of being able to run in the cloud and on perm If we have to we can “burst” into the cloud
22.
by justjake 2y ago
We're blessed with some kickass investors. They gave us just the right level of scrutiny. We were super clear about why we wanted to do this, we did it, and then they invested more money shortly after the first workloads starting runni
23.
by justjake 2y ago
Not ATM. We use it in a lot of our stack, so we will likely pull it in in the future
24.
by justjake 2y ago
Thank you! Anything you think we can do better?
25.
by justjake 2y ago
FWIW, we just pass the costs on from the current cloud providers. Doing this work will let us lower those egress prices!
26.
by justjake 2y ago
"Booo who let this guy cook?" Fair tbh We will indeed write more on this so this is great feedback for next time!
27.
by justjake 2y ago
Yup. Bingo. We've had to pass the cloud egress costs onto our customers, which sucks. With this, it'll mean we can slash that in half, lower storage costs, remove "per seat" pricing, etc Super exciting
28.
by justjake 2y ago
Winner winner chicken dinner!
29.
by justjake 2y ago
I think that's my fault BTW (Railway Founder here). I asked Charith to cut down a bit on the details to make sure it was approachable to a wider audience (And most people have only done Cloud) I wanted to start off with the 101 content
30.
by justjake 2y ago
Thanks dude <3. We are indeed doing the thing :D

More ›