Launch HN: Release (YC W20) – Staging environments made easy

[tommy_mcclung]

Hey everyone, we’re Tommy, David and Erik, co-founders of Release. (https://www.releaseapp.io). Release makes staging environments easy by automatically generating an ephemeral environment for every Pull Request.

David, Erik and I have worked together for almost 20 years starting with Erik and I meeting each other at an Internship right out of college. We met David in about 2003 when we were all working for RLX Technologies, which was one of the original blade server companies. Our early days were focused on systems management problems before VM’s were widely used. Interestingly enough a lot of the systems problems we are facing today are similar to the problems faced back then, just abstracted a few levels. Staging environments were hard then and they are hard now.

Since then, we’ve all pretty much stuck together, including co-founding IMSafer (detection of inappropriate conversations online for parents) together in 2006. David did take a break from us along the way as he became one of the early engineers at Etsy where he got a new perspective on systems challenges while Erik and I founded CarWoo! (YCS09 - online car buying made easy). David eventually made his way to CarWoo! and rejoined Erik and I after 4 years at Etsy where he was responsible for their search infrastructure and was involved in their DevOps systems. CarWoo! eventually was acqui-hired by TrueCar in 2014. We stayed on as the technology leadership team there for 5 years and led a major replatforming project that solved environments and enabled developers to iterate quickly.

Throughout our careers in doing systems engineering, starting companies, and being in and around technology there has been a universal difficulty in building environments that represent production and actually aid in getting work done vs being a bottleneck. As we’ve explored this problem with early customers, we’re getting similar feedback that’s reinforced our excitement to solve this problem.

We’re hearing some common themes as we talk with customers. Teams with just one or few staging environments have a big bottleneck in their process and can’t get product delivered as quickly as they’d like. The drift between production and the few staging environments a team may have is a problem. A lack of environments causes stakeholders to be out of the loop until really late in the development cycle and rework costs are high.

Engineering leaders are telling us how expensive in time, money and distraction away from core company objectives it will be to focus on this effort. Many times this is the reason this project (building a more flexible staging environment solutions) sits in the backlog and teams are just living with suboptimal velocity. Leaders that have invested in building an in-house solution have told us how complicated building it has been and aren’t happy that they’ve had to dedicate resources to this versus solving customer problems directly.

It’s not all bad though, as companies who have actually built and are maintaining adequate environment infrastructure have a distinct advantage in speed of delivery of complex applications. They are moving faster and that speed is a distinct advantage over companies without this capability. However, the cost of building this infrastructure is generally prohibitively high unless you’ve raised a lot of money or your application is extremely simple.

We’ve solved staging environments at every company we’ve started or been a part of throughout our careers and it’s always been the key to enabling us to move fast. We’ve learned that if developers have their own staging environment automatically created on every Pull Request, they can move incredibly fast. They are free to experiment, they can share work-in-progress changes with stakeholders early and they aren’t waiting for resources to free up to get their work done. We’ve seen ideas come alive while they were being built which has allowed them to iterate faster with more feedback and less rework.

We decided to build Release after spending countless hours talking about our experiences in our careers and when we’ve been the happiest at work. We’ve seen how powerful technology teams can be when they have enabling platforms at their disposal and how hard it can be when they don’t. We’ve always taken pride in making developers happy and more efficient. Release is the perfect avenue to solve a really big problem AND do work we love, that makes us happy.

As we started thinking about building Release, we leaned into the technology we were already familiar with, Docker, docker-compose, AWS and used that as our starting point. We felt that adding Kubernetes to the equation gave us a way to create these environments in a generic way where almost any application would run. We’ve tackled some complex environments for our early customers with lots of services and the interdependencies between them, including cloud native dependencies. Our ability to tackle complex environments has given us hope that the right technologies have emerged that make this possible now.

As we started exploring the idea, we knew Docker and containers were the baseline and we liked the starting point that docker-compose offered for running applications and defining environments. If you have a docker-compose we can run environments for you. We take that docker-compose and compile it into an application/environment definition (release.yml) that we automatically generate. Think of this as an abstraction that sits in between docker-compose and Kubernetes that gives you flexibility to define environments and resources that meet your needs.

From the application definition in the release.yml and your docker-compose we automatically generate all of the Kubernetes yaml files to run your environments. As a customer, you don’t need to know anything about K8’s. Whenever you do a PR we automatically generate all that’s needed to deploy and run your environment in K8’s. We’re interested to hear how much access customers would want to the raw K8’s ecosystem. To date we’ve had the opinion that customers shouldn’t have to deal with it, but would love to hear HN’s opinions on this.

If you’d like to give it a shot, request access at https://www.releaseapp.io We’d love to have you! We’ve tried to keep the model simple and just charge a fee for the number environments created each month by our users.

We’d love to hear your feedback. We’d also love to hear about how companies are handling this problem today. Your feedback is incredibly important to us, we know the HN community has a really unique perspective and appreciate you reading our launch post and making it this far in our launch story!

[monus]

I think that'll be pretty useful for a lot of companies but I'm not sure whether going with container count as limit will work.

Staging is where the software is tested as a whole before the production and in many cases it's more than a few containers. I'd not pay $500 for "Up to 5 containers/env" to set up a staging environment for my app that consists of many microservices deployed on Kubernetes. My two cents; change the pricing model. It's not only expensive but also container count is not that helpful. Number of environments is a good proxy for the value I get but I don't want to be punished just because of my number of containers; cpu + memory could be more acceptable.

[ashrodan]

https://runnable.com/preview-environments/

Runnable has the same offering, now bought out by mulesoft.

They charged per user.

[tommy_mcclung]

We originally started with the CPU+memory concept but as we explained it to customers it was confusing. They kept asking why we cared about CPU/memory. We're trying to proxy application complexity and our thinking was containers was an easy way to approximate that. Great feedback, we'll keep iterating and thinking about it.

[yani]

Been there done that. I would take a different route. I will start with one application and make it easy for a developer to install and run it on their computer, ideally with some dummy data. Price it as free to use, you will get tones of users. These users will need a way to get these local applications to a staging and to a production servers. Thats where you charge money and you control the entire cycle. Pulling and pushing data between live and staging sites is where the demand is and there are not many easy to use solutions.

[fraktl]

This is brilliant suggestion.

After visiting Release's site, I clicked pricing and saw $500/month for what I'd consider playground environment and my instant thought was "nope, another tool I won't use, no chance I'm paying $500 only to speak to sales later in order to agree about more money".

However, if I were charged when trying to make production work - that's something I'd pay for, if it's an application that helps with that process.

[tommy_mcclung]

I like this idea a lot. Thank you for suggesting it.

[photonios]

How is this different from Heroku review apps [1] besides that it's not Heroku?

We have this at work. Every PR provisions a new app with your code deployed on it. Since we use a mono-repo, we built a small Github bot that depending on Github labels sets up the right app.

[1] https://devcenter.heroku.com/articles/github-integration-rev...

[tommy_mcclung]

I think the main difference is support for complex applications (lots of services) and running in your own AWS account. We actually have a few customers who have been using Heroku Review Apps and their application has outgrown Heroku and they were bummed they were going to lose that functionality and were now faced with having to build that themselves. For companies that are just starting out or just have simple apps we think our Free and Professional plans are somewhat competitive (albeit it a little more work for now) with Heroku but we don't have the growing out of it issue.

[Ozzie_osman]

My team uses Heroku review apps and it's just a click to turn on (plus a config file or two if you want to copy over staging data, etc). But i can see it getting complicated if you have more complex setups.

[bfirsh]

As the creator of Compose (née Fig), I am very excited to see this. We initially created Compose with the intention of it being used to deploy to staging and production environments.

Docker Swarm was intended as the target of Compose deployments, but that never materialized because Swarm didn't catch on. I'm very glad to see someone carrying the torch in a Kubernetes world. :)

[OriPekelman]

I think it's fair to point you at my thing: https://platform.sh has been doing something similar since 2015. Based on containers (although that is not the abstraction we expose, in that sense we are more similar to Heroku). Production represents the master branch. Every other branch gets an automatically generated ephemeral staging with a full clone of all the data (and no specific configuration required). With support for microservices and multiple data backends. The whole operation takes about a minute. But this is not something you can run on your own tenant. To get production cloning (for what should be obvious reasons) we need to actually run production.

[tylerrobinson]

I’m impressed by what you guys have built at Platform.sh and not surprised to see you chime in here. Incidentally, I applied for your open PM role back in January and was rejected (algorithmically? It was about 8 hours from application to decline...), but would love to connect with you since the posting is still up. Contact info in profile.

[tommy_mcclung]

Love seeing companies in this space. Thanks for posting.

[dubcanada]

It just seems to be a docker host hooked up pull requests. Unless I am missing something there doesn't seem to be anything fancy or new.

Main things I see missing

- Ability to clone live database

- Ability to run any sort of tests

- Yet another yaml file with docker configuration in it, slightly different then every other docker configuration system.

Also seems to be twice the size of docker compose?

[tommy_mcclung]

These are really good observations and probably points to us needing to add some clarity.

I think the thing we could explain better is we take the docker-compose and use that as a starting point to define how an application will run in Kubernetes. We aren't just running Docker when environments deploy, we're running applications in K8's. We've debated long and hard about how much K8's we expose to customers. We tend to think it's complex and if we can abstract the complexity so our customers don't have to worry about it, that would be better. Interested to know what people think about how much K8's we should expose.

The reason we choose to create a new YAML file was we needed a way to define environments. docker-compose does have some stanzas for environments but they were meant for Swarm and the older versions of compose didn't map well to K8's. This file is automatically generated and attached to an application so you don't have to write it by hand, just update pieces that apply to environments. There is definitely duplication with docker-compose in this file, we may end up migrating towards just using docker-compose with the Swarm environments definitions but we haven't seen anyone using those yet.

We're working on a few solutions to seed data and database cloning. It's a really big request and will be added very soon. We do have a few ways to do it now, but they are more one-off solutions than products at the moment. Same goes for testing. We've purposefully not tried to be a CI/CD replacement at the moment. Most of our customers are already using Jenkins or Circle so we decided to integrate for now. We are going to add simple test running soon.

[hashhar]

We had something like this built at my previous org using nothing but Jenkins API and plain docker with a few bare metals for persistent stuff (RDBMs, Solr, Redis etc.). It was created circa 2014 so no fancy stuff like K8s.

I miss it a lot at my new org. Will definitely look at this and suggest to leadership if it aligns.

[iamEAP]

I may be at a place where this would be useful, so I signed up! That being said...

At this point, one-click (or one command or one PR open) pre-production environments are almost table stakes for PaaS offerings. This kind of functionality was the primary reason we moved from self-hosted to PaaS (Pantheon) back in 2012/13 at a prior gig. Heroku (as mentioned in other comments) offers similar functionality these days.

Given you probably won't have much traction with teams who are happy on PaaS offerings like the aforementioned, am I right in thinking your market is either people doing completely bespoke docker stuff (how many of those are there), or people whose apps don't neatly fit (either due to size or complexity) into an existing PaaS offering?

If that's the case, I wonder if docker is the wrong abstraction-point. Perhaps it'd be better to be a glue layer between a VCS and something like a Terraform configuration or a Pulumi project.

I also wonder an open source model could be a winner here, too.

[tommy_mcclung]

Many PaaS offerings do some version of this, but we're targeting companies who aren't using PaaS. Specifically companies that are in AWS natively (other could providers coming soon). The reason for this is they are the ones who tend to need to build this from scratch and the market for companies in the cloud is... well... huge. They tend to want PaaS features but have to build it themselves. That's where we are headed. There is also a market for those that need to move off of PaaS due to complexity or technical needs that those PaaS offerings don't support. We think this is a sweet spot.

As for Docker, we choose that because it's kind of table stakes now. We didn't initially start here, we were thinking more inline with what you were saying initially about Glue between VCS and Terraform. But as we started engaging with users, it was clear that Docker, and more specifically docker-compose was the starting point because what we lacked was a good definition of the services people wanted to run and we didn't want to invent something new for this. We do see a place for Terraform in the near future in our offering.

We also had the good fortune of running into Ben Firshman (founder of Fig/docker-compose) recently and he told us what we're building is what they had envisioned in the early days building Fig. We just brought Ben on as an advisor to help us think through that vision and to also help us with our open source strategy. Because, as you mentioned, we believe that open source is going to play a critical role in how we evolve this business.

[endymi0n]

Nice idea and all the best of luck to the team, but if experience has taught me anything, it's that the staging topic is extremely hard, mostly due to conflicting requirements.

On one hand, what you want is as much prod/stage parity as possible, however there are often various side concerns that go against the ideal of "isolated, but equal".

Just from the past few years, I can remember dozens of instances where "easy" staging wasn't an option. Staging services actually needing access to various levels of (partly anonymized) prod data, partly read-only, partly local. Deactivating caching on stage for better testing. Separating or smartly accessing cookie domains from others. Databases that are far too heavy to keep a second set of (especially data warehouses).

In the end, "staging" for me is a problem class that I don't see anyone "solving" in the way "dependencies" won't ever be solved, but I'd be super happy to be proven wrong.

[gingerlime]

There’s another YC company doing this called dockup[0] How are you guys different/better?

We tried dockup but things like DBs, authorizing Facebook and google oauth, subdomains, Stripe webhooks etc became tricky quickly. We ended up doing our own thing with docker compose and some deploy scripts. It’s a bit hairy but dockup wasn’t much cleaner either and it’s one less thing to trust (and a bit of NIH I admit)

Edit: one particular limitation of dockup that probably pushed us was the time limit on the environment. Our use case required longer running environments in some/most cases.

[0] https://getdockup.com/

[erik_landerholm]

It’s good that multiple companies are trying to solve the problem, as it’s a big problem. I’ve not used Dockup, but from reading the docs and from other feedback I’ve heard, their solution seems like a more involved process to get running. And I think you pointed that out in your comment.

From our basic understanding of Dockup that primarily is a result of reading their documentation, it appears that the customer has to do a lot of the DevOps/AWS/Kubernetes work on their own to get things going. A big point of differentiation for us is we’re trying to automate as much of that as possible and make it accessible to developers without having to get DevOps involved (or get them involved as little as possible).

We have a solution for database and seed data that we are currently testing with customers. As far as auth'ing with 3rd parties we’ve had to solve this problem for ourselves (our integrations with Github/Bitbucket present this issue with ephemeral environments) and our approach is to take those learnings and create simple generic solutions for them. Right now we would solve that with any customer as part of our onboarding.

I’m not quite sure what challenges you had with subdomains while using Dockup. We auto-create subdomains for all your staging environments including managing dns, either in our cloud or in your AWS account. We have some documentation on how you design your architecture/app for staging environments here: https://docs.releaseapp.io/multiple-environments.

Dealing with subdomains ends up being part design issue (not hardcoding IP/host names, etc) and part using a system that can handle all the complexities around dns, and networking of your services.

We don’t have time limits on the environments. We will be adding administrative settings to allow customers to control the life-cycle of their staging environments. At this moment, they can be created manually or through a pull request. If they are created through a pull request, they are automatically removed when the pull request is merged or removed. But, this is how Release works at the moment based on customer feedback and can be adapted to your use case.

We have worked on this problem all through our careers. We are encouraged by all the companies trying to solve this issue. We feel our approach is unique in its simplicity for the end-user, but we are aware of the complexities inherent in generalizing an approach for other people. It’s hard.

I really appreciate your feedback and would love a chance to show you what we are doing and hopefully we are different and useful enough for a system as complex as yours. If you want please reach out at founders @ releaseapp .io

[gitgud]

Great idea, and is exactly what I was thinking about a few months ago actually.

I'm not too sure about the name of the company though "Release", kind of an un-searchable name. Nobody will be able to find you in Google without significant SEO against business/tech blogs. Try searching "release app" or "release company" it's just too generic.

Sorry to be critical of the name, but I think it's much more important than people realise. I genuinely like product though!

[tommy_mcclung]

Don't be sorry! I think we can all agree, picking a company name these days is a massive challenge for lots of reasons, you've pointed out one we didn't index on. We like it because it's a good name for what we're doing. I guess we just have to take on the challenge of becoming relevant and making our product awesome so we become relevant.

Thank you for the kind words about what we're building.

[matisoffn]

I worked multiple years in an organization led by the founding team. Just dropping a note to say that the team is top-notch, and they are maniacal about listening to customer feedback.

They advocated for and implemented a strikingly similar product within the organization, and it was used for all deployments: development, test, staging, production, etc. The system was a crucial aspect of everyday development and extraordinarily helpful for working with cross-functional partners.

[webmons]

I work at mostly early stage startup and setting up ONE staging environment is always the default option. Sooner rather than later, we'd run into broken staging, botched demo, etc... and waste countless hour debating on how to make it better. Ephemeral environment based on PR came up often as the ideal solution but wasn't implemented because it's not easy

Using release at my company now and I wish they existed 5 years ago

[flippyhead]

Finally! We've been wanting something like this for a long time.

[JensRantil]

"Non-Production Environments Have Diminishing Returns" https://medium.com/@paulosman/production-oriented-developmen... Exactly my insight from years of fighting staging environments and the issues with them. If I'd ever start a company I'd skip a staging environment all together. Instead of focus on staged/gradual rollouts, solid automatic testing before mainline and feature flags.

[das_keyboard]

This is what the site looks to me with Firefox: https://imgur.com/ILi5zEK This does not seem right.

[tommy_mcclung]

We found the issue. When you have "Delete cookies and site data when Firefox is closed" set we weren't handling things correctly. Fixed and pushed. As an aside, we couldn't reproduce this locally and used an ephemeral environment to figure it out. Let me know if it works for you now.

[tommy_mcclung]

Thank you for pointing this out, you are right, that doesn't seem right. Fixing now.

[dmundhra]

Do you handle setting up cloud specific environment like SNS, SQS, Lambda, etc.. and initiating it with seed data needed to create a complete environment for testing?

[tommy_mcclung]

We do not manage the setup of cloud native services just yet, but it's on our very near term roadmap. Seed data is something we're currently working on building now with a few of our early customers. We will tackle that first, then the cloud native services.

[dunky11]

The website is really slow. You got images which are 3700px in width and 1.2mb large on the landing page. You should resize them to the width you really need, probably 1000px in width max. Use .png for images which are transparent and .jpg for images which are not. Also don't forget to compress them. Google Chromes Lighthouse shows an optimization of 16seconds on 4G mobile by resizing/compressing images alone.

[mleonhard]

A deployment that is deployed differently from prod is not staging. It's test.

Can releaseapp.io work for prod?

[tommy_mcclung]

Yes, we have support for ephemeral environments, permanent staging environments and production environments. Release is currently running on Release in all three of those states. We've decided to focus on staging because that's where our customers are having issues today. Our longer term plan includes a lot of things in all three categories.