Launch HN: Dockup (YC W19) – On demand staging environments for dev teams
My co-founder and I were colleagues at our previous job (for ~6 years) where we worked as consultants, mostly working on Rails, React and Elixir projects and had the luck to work closely with many engineering teams. We often saw that teams would slowly lose confidence in their code as their codebases and team sizes grew and code changes would take longer to ship. At a payments company that we worked for, things often worked fine in dev but broke in production and eventually they started having company wide meetings before teams could deploy anything to production. Wanting to help developers ship faster and with more confidence, and also to scratch the itch of writing something in Elixir, we started building a tool as a hobby project, which eventually turned into our product.
Honestly, at first I thought that if we could build it, anyone else could build it internally too and no company would pay money for this, until we actually started talking to companies which have done it. We learned that it usually takes a few months for a developer to build an internal tool that automates PR review deployments. Most engineers told us they don't like having to support this set up and keep it running after they've built it and moved on to solving other problems. We faced many problems on the way, for example - the need for pre-seeded prod like databases for testing features, being able to support architectural changes (for example, adding a message queue in the tech stack and testing it with Dockup) etc. We have now reached a place where we are able to onboard most of our customers without having to build custom features each time. We are excited to share what we have built with all of you! We are sure the HN community will have many knowledgeable engineers who have tried solving this problem and we're looking forward to hearing your thoughts.
If you want to try Dockup now, you can do it by running the Dockup agent on your servers. If you don't want to run your own servers, you can request access for the managed Dockup cluster by going to our pricing page and we'll roll out access in a couple of days. Pricing starts at $75 for small teams.
Thank you for reading!
54 comments
[ 3.6 ms ] story [ 142 ms ] thread- How much configuration is still required by the end user to leverage Dockup? How would it be different from a Vagrant/Docker setup where you would define a Vagrantfile and Dockerfile?
- Why make pull request reviews with a development environment rather than a slimmed down production environment? Testing turnaround time?
- Do you guys anticipate on-premise deployments of Dockup?
Best of luck!
- Regarding configuration - you need Dockerfiles for your apps and also configure environment variables and ports in Dockup. We call this configuration a "blueprint", which once created will be the template for your automated deployments. Unlike Vagrant, Dockup runs your apps on the cloud and you get URLs in your slack channel when someone opens a PR.
- Our pull request reviews (we use Dockup while developing Dockup :D) actually use production environment. We simply use a postgres container as the database and turn off analytics in our Dockup environments.
- Yes we do get requests for on-premise installations and we do support that. In fact, when we started, we only supported on-premise and later made the SaaS version. If you want to just self-host the infra and use Dockup UI, you can do it right now by signing up for the self-hosted plan.
Dockup has these:
- Seeding DBs with prod-like data is easy and works super fast so you don't have to wait around for a long time until you do a database dump/restore. We can do this in Dockup because we can maintain a pool of single-use DBs for your deployments.
- Deployment form to mix and match different versions of your apps (example: you can try how branch-foo of frontend and branch-bar of backend work together)
- Users who know how to write Dockerfiles can easily setup Dockup. Many of our users are project managers and QA and they find the UI easy to use.
On demand envs for teams is a incredibly liberating experience for people who have been tied down to a single or small number of environments forever, our devs have been very happy with it. There are some interesting problems on demand environments create that persistent environments don't have, like data seeding for your apps (as naive state is an env comes up blank), extracting secrets/keys/credes/certs from the env now that they are different everytime you deploy etc. We have patterns for these problems now and has really forced us to mature our process.
quick fyi, it does not compete with OP's product.
1. branch off of master
2. write a bunch of code that runs the risk of breaking stuff
3. deploy it to our already existing developer/staging environment
4. test it. if it is good, promote it to QA/UAT/CAT
does Dockup assume that companies don't already have the 3 main environments (dev/CAT/prod) set up?
Why would my service be worth anything in isolation? Usually when I deploy to staging, it is after I've already made e2e+unit+integration tests work locally, so I'm checking how live databases/load balancers/routers/etc. work in staging.
At the company I worked at, we built something similar using Heroku free dynos :) So that you can tag a PR and it automatically created a staging app using free Heroku dyno, it even came with a free database. The setup works but also quite spotty.
How can you deploy multiple staging environments?
I guess I kind of get it now that I think through it.
Say you need 10 services for staging to work. They all talk to the staging database...
Does this DockUp thing also allow you to configure to deploy a database so developers aren't fighting over data/migrations in staging?
It sounds like a containerized development environment, but it's really only as good as the configuration job that is done for it.
How do I test new load balancer rules? Gotta have all of the load balancer images + configuration files in.
This is incredibly useful with many interconnected codebases have related changes (I know, bad SoA. best practices are hard). Then I can point review-3918.SERVICENAME.service.XXX.stag's connection string to review-1111.SERVICENAME.service.XXX.stag to ensure that everything is working as expected.
0: https://getstream.io/
(Really, you just launched exactly the same features what we have already internally. :) )
Good luck.
[1] https://medium.com/@kevanahlquist/dockerui-at-bluestem-2890b...
I don't quite understand this. Why wouldn't I want to spin up another postgres DB in AWS for testing?
I think that's what I'm a bit stuck on. Being able to spin up a test environment on demand is cool. But if I'm going through the effort to do that, why not go through the effort to do the same for a production environment? Then I can use the exact production configuration to run my tests.
But Docker for development really still feels so annoying and in the way. So I've just been using a Python virtualenv and a postgres instance installed directly on my machine. I tried to make docker dev work but it just always felt in the way, between my dev tools and the environment. It's been working fine but I'm sure there's some who will hand wave and insist this is a problem.