
Launch HN: Release (YC W20) – Staging environments made easy - tommy_mcclung
Hey everyone, we’re Tommy, David and Erik, co-founders of Release. (<a href="https:&#x2F;&#x2F;www.releaseapp.io" rel="nofollow">https:&#x2F;&#x2F;www.releaseapp.io</a>). Release makes staging environments easy by automatically generating an ephemeral environment for every Pull Request.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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&#x2F;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.<p>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.<p>If you’d like to give it a shot, request access at <a href="https:&#x2F;&#x2F;www.releaseapp.io" rel="nofollow">https:&#x2F;&#x2F;www.releaseapp.io</a> 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.<p>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/](https://runnable.com/preview-
environments/)

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

They charged per user.

------
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...](https://devcenter.heroku.com/articles/github-integration-review-apps)

~~~
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.

------
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
Thanks for the comment, I totally understand what you're saying. We need to do
a better job of explaining that we can run production environments as well as
staging. In fact, Release runs on Release.

------
OriPekelman
I think it's fair to point you at my thing:
[https://platform.sh](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.

~~~
OriPekelman
Ooh we don't reject anyone algorithmically. So a real trigger happy human was
there. And I see no notes left. Which is bad. So I'll review.

------
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. :)

------
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.

~~~
knefvjke
So how is this different from
[https://github.com/kubernetes/kompose](https://github.com/kubernetes/kompose)
? What is the value add here?

~~~
tommy_mcclung
Kompose is a really great tool in converting docker-compose to K8's yaml. But
from there you are on your own. We've worked with a few companies that started
down this path, realized how difficult K8's was and gave up. We handle
everything in the K8's world so customers can just focus on their apps and
simple environment definitions.

------
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.

------
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.

------
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.

~~~
iamEAP
Thanks for the detailed response! It all makes sense, and it sounds like y'all
are getting good advice.

My gut take on docker vs. config management came from the trend of IaaS
providers moving higher up the chain in the services they offer (it ain't just
compute anymore). So spinning up an ephemeral environment that also, for
example, had its own SQS instance, or an Aurora DB, or (across clouds) had a
Firebase DB or Cloud Scheduler configuration, seems like a very common use-
case.

Gotta start somewhere though, and docker's probably a good place to do so.

Looking forward to trying it out!

------
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/](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](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...](https://medium.com/@paulosman/production-oriented-
development-8ae05f8cc7ea) 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](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.

------
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.

------
striking
Welcome, Release. A question: do you plan to support features of clouds like
AWS Lambda?

------
mishkinf
Looks like an enticing solution to the age old problem! Great work guys

------
markivraknatap
No Gitlab ?

~~~
aexvir
Isn't it supported natively?
[https://docs.gitlab.com/ee/ci/review_apps](https://docs.gitlab.com/ee/ci/review_apps)

------
DantesKite
Hacker News comments always remind me of this quote:

"People who are brutally honest generally enjoy the brutality more than the
honesty."

\- Richard Needham

------
marvindanig
What is this with "Launch vs. Show" thing by YC incubatees lately? Is it
typical "us vs. them" thinking or does YC also promote these projects on HN
over others to let them appear on the frontpage much more easily?

~~~
slap_shot
Show HN: community members showing HN what they've built

Launch HN: YC portfolio companies showing HN what they've built, often within
their batch (but can sometimes be years after they went through YC)

~~~
capableweb
marvindanig understands that, judging by their comment. But the portfolio
companies used to do Show HN, just like everyone else. Lately, they've started
doing Launch HN instead, so they are separate. I think the question is around
why that changed.

~~~
slap_shot
interesting. do you have an example of a Show HN that was an YC incubated
company that the time of the post? (I believe you, I just can't find one as an
example).

[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Show%20HN%3A&sort=byPopularity&type=story)

It looks like Launch HN has been a thing for at least three years:
[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Launch%20HN%3A&sort=byPopularity&type=story)

