We're Emil and Yuva, co-founders of Dockup (<a href="https://getdockup.com" rel="nofollow">https://getdockup.com</a>). Dockup spins up on-demand environments so engineering teams can quickly test their code changes. When you open pull requests, Dockup creates disposable environments automatically and delivers URLs to your chatrooms; engineers don't have to wait their turn to manually deploy to a staging server for testing their code changes. Anyone in the team can then click on these URLs and preview features before merging pull requests. Because each environment has all the services in the tech stack, it lets you catch bugs which usually happen only in production.<p>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.<p>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.<p>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.<p>Thank you for reading!
> It spins up containers that simulate your tech stack, but it won't be an exact replica of your production infrastructure. For example, if you use a managed postgres DB in AWS in your prod environment, in a Dockup environment, you would use a postgres Docker container that's started using the official postgres image.<p>I don't quite understand this. Why wouldn't I want to spin up another postgres DB in AWS for testing?<p>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.
As a manager of a remote team, I can see how this can be doubly useful to me! We already use Docker for development too but reviews still involve stopping what I'm doing to pull another developer's code to test and merge. I couldn't find any documentation for Dockup on your website. Is documentation available only if I'm signed in? I was just curious to see how it can be setup before signing up for an account.
I like it. Back in 2015 I built something similar[1] for my company and it helped us make the transition from time-bound releases with QA on mainline to per-PR QA and CI/CD.<p>[1] <a href="https://medium.com/@kevanahlquist/dockerui-at-bluestem-2890bf1bcd45" rel="nofollow">https://medium.com/@kevanahlquist/dockerui-at-bluestem-2890b...</a>
How is it different from Heroku Review apps? (<a href="https://devcenter.heroku.com/articles/github-integration-review-apps" rel="nofollow">https://devcenter.heroku.com/articles/github-integration-rev...</a>)
This is great. Setting up proper staging environments has been on our procrastination list for a long time and as a small team, we haven't invested engineering hours for a real setup yet. If this simplifies the process so much that we barely need to think about it, I totally get the value.
I have been searching and waiting for someone to build this! Thank you so much! Currently reviewing code is a guessing game. "Does it actually do what it's supposed to do? I don't know but the code looks sound." I have only the code to reference and maybe screen shots if they're provided. I'm not going to spend the time to download the diff and deploy it myself just to see if the application is doing what it's supposed to.
Interesting proposal! I have a number of questions:<p>- 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?<p>- Why make pull request reviews with a development environment rather than a slimmed down production environment? Testing turnaround time?<p>- Do you guys anticipate on-premise deployments of Dockup?<p>Best of luck!
We have our own version of this -- we're fully remote, so it's an important thing to have. Basically we can deploy a full on-demand env with a single command. It's very useful.<p>(Really, you just launched exactly the same features what we have already internally. :) )<p>Good luck.
I have this problem, we could have a lot of branches but only a certain number of environments e.g. dev, qa, stage etc.. So would this tool allow me to create environments dynamically so that I can test each branch standalone.
Why are you not listed on this page? <a href="https://www.ycombinator.com/companies/?batch=w2019" rel="nofollow">https://www.ycombinator.com/companies/?batch=w2019</a>
I always thought that the 'W' in YC batch numbers stood for 'winter', or isn't it? Or is 'W19' in the title a typo and should it be 'W18'?
Suppose my application is dependent on the subdomain like "customer1.wasdapp.com". Is your application able to spin up "customer1.wasdstaging.com"?
Congrats on the launch! Any relation to Stream [0]? Your logo is very similar.<p>0: <a href="https://getstream.io/" rel="nofollow">https://getstream.io/</a>
As it is relevant .. plugging-in my own startup, platform.sh We do this with another twist ... our per-branch ephemeral staging clusters contain a full snapshot of production data. We believe strongly in immutability so what you are running in production is precisely what you tested in QA... And because production cloning relies on copy-on-write primitive it is basically immediate (think more in the dozens of seconds rather than multiple of minutes).
I'm confused why I'd use this. My flow now is:<p>1. branch off of master<p>2. write a bunch of code that runs the risk of breaking stuff<p>3. deploy it to our already existing developer/staging environment<p>4. test it. if it is good, promote it to QA/UAT/CAT<p>does Dockup assume that companies don't already have the 3 main environments (dev/CAT/prod) set up?<p>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.