Show HN: Layer – Get a dozen staging servers per developer

We're Lyn & Colin and we built Layer - It creates a unique staging server for every commit.

Before Layer, I was CTO of a startup with a 10-person developer team, and dealing with staging servers (and end-to-end tests) was one of the most annoying parts of our workflow.

Layer lets you define staging servers the same way you define Docker containers, and get a unique one for every commit going back a week. We run them in the cloud, so there's no need to pay for AWS servers you're not using.

Also, if you're running a webserver, you get a unique URL for each unique server automatically so that you can post it to a slack channel and get feedback immediately.

When we're setting up the staging server, we use the same sort of cache as Docker so that you can skip repetitive tasks like setting up a database or running database migrations if they haven't changed.

Would love to get your feedback, it only takes five minutes to do the onboarding tutorial.

http://runbot.odoo.com

(it's an internal tool, don't look for a pricing page)

So far we support Firebase and their Firestore, RealtimeDB, and Cloud Functions. In action, the development with Foundry looks like this:

- (1) Start Foundry session in your terminal

- (2) Specify a slice of your production Firestore/RealtimeDB we should copy for you

- (3) Specify what Cloud Functions we should trigger for you and with what data

- (4) Every time you save your code we trigger those functions as you specified and send you back the output

Every development environment is created for each developer separately on the fly (it takes less than 30seconds to have your environment ready). You don't have to wait minutes for your Cloud Functions to get deployed. You get a response usually in just a few seconds.

We are also working on a new feature that will make it possible to have one "master" always-online environment that is publicly accessible.

The "spin-down" feature sounds like the killer -- the only reason we didn't have an environment per build already is because it would be cost prohibitive. Instead, we tried to time-slice with a static set of staging servers... very frustrating with a 50 person team.

Cool stuff! I worked on a very similar project for a small chunk of my life. I was a PM whose life was made a lot harder by not having a tool like this and when I joined a startup that had built a similar tool internally, I realized that it would be a great business. I want to provide some free (and unsolicited) advice:

Your number #1 challenge is going to be go to market strategy. There are actually a number of companies that have tried to solve this problem and either outright failed or seemingly hit some bumps. YC funded a few of them: Release, FeaturePeek, Dockup. There's also a company called Runnable that was acquihired by Mulesoft. Initially I was encouraged by the proliferation of companies in the space - we couldn't all be wrong. In hindsight I should have realized that it wasn't as rosy as I had thought since it doesn't seem like these companies have had gangbusters success.

In my experience, there are roughly three types of pushback you're going to get from potential customers:

1) We can build that better in a week. This one is very difficult to overcome because at the end of the day it's not really about the truth of the statement, it's more about the engineering skill of your prospect. Building this product is a unique and interesting engineering challenge, and I haven't met a DevOps person who wouldn't be excited to try to build it themselves. I tried a lot of different approaches but have never successfully convinced someone it would be a lot easier, faster and more efficient to buy an already existing solution from us. Your mileage may of course vary.

2) Our setup is too custom to work with any generic tool. This one is probably pretty frustrating to hear since you folks have clearly put in a lot of effort to make it work with a variety of build configurations. The interesting thing here is that this reason can often then turn into (1). Our solution required people to containerize their app if it was not already and most people replied that if they were going to do the work to containerize their app, they would just do a bit more work and build this internally.

3) My database is too big/too sensitive to work with this. Many startups have small databases that can easily be copied quickly. However, some have multihundred gigabyte ones that are too large to copy on demand. You either have to include that latency in the product which in my opinion makes it borderline useless, or figure out some way to work around it. You can use RDS snapshots but by our calculations those will be quite expensive. You can hope your customers have some test database (they don't) or you can try writing back to their shared staging (or more realistically) their production database. None of these options are realistically very attractive.

All of that said, it's clear you have some really cool technology here. One thing I'd suggest you'd look into is a related market: developer environments. Most companies I've worked at have software engineers putzing around for the few days/weeks getting their dev environment set up. This is a very expensive waste of time IMO. If you could provision a cloud development environment on demand, that doesn't require any scripts to set up or database migrations to run, that would be huge. The value of skipping that ~2 week setup time multiplied by the number of engineers a company hires really begins to add up. Just my 2c.

Happy to chat about this more if you're interested. I don't feel like sharing my contact info on HN but if you are determined enough I'm certain you can probably get in touch. Best of luck :)

Will give this a try.