Fly.io Blog

Hi HN! I’m Grant, creator of (https://cicada.build). Cicada lets you write CI/CD pipelines in TypeScript and test them locally.

We built Cicada because of our own struggles building CI/CD pipelines. YAML is cumbersome, not type-safe, and does not scale well for large pipelines. Sharing logic across pipelines is hard and most providers don’t let you test your pipelines locally.

Cicada lets you

1. write your pipelines in a real programming language. Using TypeScript gives you type-checking, syntax highlighting, and in-line documentation out of the box. It also lets you extend your pipelines by hooking into the entire TypeScript ecosystem of packages and modules.

2. test your pipelines locally. All jobs are run in containers. This means you can test them with Docker/Podman. It also means you get great caching.

3. run your pipelines on our cloud. Pipelines are checked into your repository and run when triggered by an event in your repository (like a commit/PR), when triggered manually, or at a defined schedule.

We use Deno [0] to create pipeline definitions, Docker Buildkit [1] as our build engine, and Fly [2] for our cloud hosting. Our CLI is written in Rust for speed and stability. The hardest technical challenge we faced was writing BuildKit bindings for Rust [3].

Cicada’s client is fully MIT OSS (the CLI, BuildKit integration, and SDK) [4]. Our dashboard and cloud runners are closed source. The cloud runners have a generous free tier for individuals and are cheap…

Would it be right to say this is sentry.io meets envoy, grpc, and konghq? Super interesting. Congratulations.

How do I manage my API integrations, you ask?

Global Accelerator (GLA) is a key infrastructure piece for a HA service I'm building but for the data-plane. It is such a hassle-free but slightly expensive way to vend anycast IPs (no need to purchase ASNs and/or announce routes from colos across the globe) and have the traffic load-balanced to 25+ AWS regions, that I recommend it instantly to anyone architecting HA services. https://fly.io and https://stackpath.com/edge-computing are viable alternatives. Cloudflare announced MagicTransit which isn't as smooth as AWS GLA in terms of developer experience, whilst Azure and Google offer global-load-balancers, too, and may be even before AWS announced it in 2018? So, really, I think utilizing GLA is something folks should do if they run global HA services. The only issue with using NLB behind AWS GLA is the client-IP is not preserved. In our case, we needed it, so we had to get creative with sticky routing and port assignment (listeners) to do load-balancing / traffic-shaping.

Another HA trick I plan to employ is to use Cloudflare-Workers (200+ PoPs) to front https-traffic to our control-plane endpoints. It lacks observability, monitoring, and alerting unless you're on Cloudflare's enterprise plans. The rate-limiting option is expensive ($0.05 per 10k good requests). I'm sure there's no way to queue requests…

This kind of problem is present in most of the currently available crop of coding agents.

Some of them have default settings that would prevent it (though good luck figuring that out for each agent in turn - I find those security features are woefully under-documented).

And even for the ones that ARE secure by default... anyone who uses these things on a regular basis has likely found out how much more productive they are when you relax those settings and let them be more autonomous (at an enormous increase in personal risk)!

Since it's so easy to have credentials stolen, I think the best approach is to assume credentials can be stolen and design them accordingly:

- Never let a coding agent loose on a machine with credentials that can affect production environments: development/staging credentials only.

- Set budget limits on the credentials that you expose to the agents, that way if someone steals them they can't do more than $X worth of damage.

As an example: I do a lot of work with https://fly.io/ and I sometimes want Claude Code to help me figure out how best to deploy things via the Fly API. So I created a dedicated Fly "organization", separate from my production environment, set a spending limit on that organization and created an API key that could only interact with that organization and not my others.

As someone that was there at Heroku after the acquisition, I don't think you can state that since the acquisition it's been consistently downhill. There isn't much debate that things have stagnated in the last 5-7 years which is a longer story on why probably.

Some examples of innovation that happened and were launched after the acquisition: buildpacks (at the time of acquisition Heroku was still Ruby only), Heroku Postgres launched forks/followers/dataclips all after the acquisition, review apps came several years after. Salesforce may have had an eventual hand in it, but there was still a lot of innovation happening due to the folks there in the near to mid-term after the acquisition for several years.

All that said, very excited for the new crop of players in the space. There are a number of companies trying to be a cheaper or more stable Heroku. Personally I'm excited about the ones that are taking their own unique approach. https://www.fly.io and https://www.railway.app are two that to me seem to bring their own perspective vs. just trying to recreate Heroku as a carbon copy clone. There are a number more in the jamstack space that have become staples such as Netlify and Vercel which are also doing great things.

We're already there. We have huge companies using elixir and phoenix, with phoenix powering the web platform for the majority of them. Several great case studies exist on elixir-lang.org if you're interested, ie:

Pepsi:
https://elixir-lang.org/blog/2021/04/02/marketing-and-sales-intelligence-with-elixir-at-pepsico/

Heroku:
https://elixir-lang.org/blog/2020/09/24/paas-with-elixir-at-Heroku/

Change.org
https://elixir-lang.org/blog/2020/10/27/delivering-social-change-with-elixir-at-change.org/

And of course Bleacher Report, which has been on Phoenix since 2014, well before 1.0.

On the sponsorship side, DockYard invested in my work for the last six years where I spent the majority of the year working on oss, and I've just joined https://fly.io where I'll spend 85% of my time working on Phoenix and related libraries. So we are well covered on the corporate sponsorship side. We also have Michael Crumm on the Phoenix team who works at Cargo Sense, where they support a portion of his time working on LiveView. Of course it would be great for other large companies leveraging value out of our work to give back, but we're well established on the sponsorship side :)

do you remember writing this? https://fly.io/blog/carving-the-scheduler-out-of-our-orchestrator/

this was amazing post. i enjoyed reading it, it was relevant to some work stuff i was battling with. the linked articles at the end were amazing too. i had tonnes of respect for fly.io and yourself because of these posts. technically informative, clear, engaging. great stuff.

the llm post? complete polar opposite.

> I would like to take this moment to apologize to you, personally, for not giving a shit about "AGI". I wish I could tell you I've come to see the error of my ways, but I continue not to care about it.

thanks for the snark, and kinda proving my previous point about the tone of the article that was supposed to be a personal blog post and then ended up on a company blog https://news.ycombinator.com/item?id=49052217