I spend a lot of time in CI (building https://namespace.so) and I agree with most of this:

- Treat pipelines as code. - Make pipelines parts composable, as code. - Be mindful of vendor lock-in and/or lack of portability (it is a trade-off).

For on-promise: if you're already deeply invested in running your own infrastructure, that seems like a good fit.

When thinking about how we build Namespace -- there are parts that are so important that we just build and run internally; and there are others where we find that the products in the market just bring a tremendous amount of value beyond self-hosting (Honeycomb is a prime example).

Use the tools that work best for you.

Hugo here, founder at Namespace. We built Foundation based on what we learned from building Boq at Google — the app platform that drives the dev/prod workflow of many of Google’s main apps.

We leaned heavily on composition that spans build, test and production. You can define assets that yield code-level infrastructure definitions and also are automatically configured based on environment (dev vs test vs prod).

It was great building it, and we use it to build Namespace (namespace.so); our development-focused platform.

100% -- EC2's general purpose nature is not in my opinion the best fit for ephemeral use-cases. You'll be constantly fighting the infrastructure as the set of trade-offs and design goals are widely different.

This is why CodeSandbox, Namespace, and even fly.io built special-purpose architectures to guarantee extremely start-up time.

In the case of Namespace it's ~2sec on cold boots with a set of user-supplied containers, with storage allocations.

(Disclaimer, I'm with Namespace -- https://namespace.so)

This is very cool.

We built something similar in https://github.com/namespacelabs/breakpoint but the more general purpose nature here is great.

This is very useful. I needed this at least 10-20 times in the past but didn't know it existed.

I no longer need it in a CI context but I could imagine this getting really handy when some weird thing happens during the build stages of a docker container too.

Omg you have no idea how many times I wished I had something exactly like this! Going to test this out this week and almost certainly integrate this into my team’s workflow.

Let us know how it goes!

This is very cool. Checking it out! Thanks!

Hi -- Namespace's CEO here; if you have a chance, please drop me a note at hugo-at-namespacelabs.com; I'd love to hear what we could be doing better in the UI, and product overall. Thank you!

Hugo @ Namespace (https://namespace.so)

You can use namespace.so today which provides the best performance for Github actions in the market.

With the added capability of cache volumes: high-performance zero-cost cross invocation caching.

Built by a team of ex-Googlers and ex-Digital Ocean.

Disclaimer: i’m founder and ceo (happy to answer any questions!)

Looked into your product today. Only found a way to make docker build commands faster.. while that's a big part for sure. It has nothing to do with our needs right now.

We have a similar vision at namespace.so; we are starting with development and testing. But that’s the start.

(disclaimer: I’m part of the team)

Namespace Labs https://namespace.so

Looking for: Frontend / Design Engineers GTM / DevRel

Prefer near CET tz; remote friendly.

Namespace wants to help developer teams do more with less: faster cycles, and more focus on what matters.

Email me directly: hugo AT namespacelabs.com

Competitive pay and generous equity. We believe in shared incentives.

Add breakpoints (static or on failure) to GitHub Action workflows; and SSH in to understand and debug failures. Open-source.