Show HN: Deploydo – Deployment made easy | Hacker News Reader

Show HN: Deploydo – Deployment made easy

deploy.do

46 points_query35 comments

The idea of these hosted deployment systems always scares me. Essentially you have no choice but to open SSH to the universe. This is far beyond best practices for at least a couple reason. The first would be that if at all possible you should be hiding SSH behind a VPN so that casual or not so casual attempts at breaking in to the server are made that much more difficult (this makes even people somehow getting a stolen private key a non-issue). The second would be that giving an 'unknown' third-party this kind of access to your systems leaves you open to them being exploited and then exploiting you (and this scenario seems much more likely than someone guessing your password if you are using one on SSH for some reason).

All in all, deployment seems like something to me which I'd always want to keep in-house.

I'm comfortable with having a company I trust enough handling deployment. In order to trust them I have to see them do difficult things well and it probably needs to be more than just a couple people. A small deployment service like this will probably remain in the area where I don't know enough about them to trust them. This is why I turn to Continuous Integration tools (CircleCI) or Project Hosts (Beanstalk, Springloops) for deployment. By observing them doing complicated things I get the feeling that they know what they're doing. Perhaps OP should think bigger.

But those complicated things (CI) are fairly different than managing deployments securely...

I personally wouldn't trust CircleCI to do this stuff either. They already don't exactly have a great track record for security.

Upon thinking about it, I agree. I don't want CircleCI to have the SSH key.

I think webhooks are a good model. At worst it could deploy at the wrong time (which would be pretty bad).

Would be a nice tool if you could host it yourself though.

I was recently facing the decision whether to deploy from codeship.io directly or not. In the end it turned out not possible due to technical reasons. So I repurposed my old CI server and turned it into a 'continuous deployment' server which integrates well into github. You can easily run it on your own system, it's just one (almost static) binary. https://caurea.org/2014/07/01/mudbath-is-now-a-continuous-de...

the service I use gives me a list of 2 IPs which I add to my Firewall.

It isn't exactly open to the world.

> Ever asked yourself why deploying your projects to your servers is such a pain?

Personally, no. I haven't heard it from my peers either. I just use rsync and quick scripts; others use PaaS (self-hosted or managed) that generally handles deployment pretty neatly.

The only place I've heard complaints about deployment is inside of large multi-tier organizations, where the problem boiled down to communication issues between dev and ops, not tooling.

I suspect I'm supposed to be the target audience here, but I'm not sure what problem this solves for me. On a first impression this looks mostly like a way to lock myself into a workflow that leaves a lot of unanswered questions (re: server security, platforms/frameworks supported, etc), with very marginal benefits.

> I just use rsync and quick scripts How do you handle zero-downtime deployments with rsync? Also what about rollbacks, how do you handle these?

In case you have team of a few people, how do you know what already got deployed? How do you know if anyone is deploying just at the moment when you are deploying something?

We wanted to solve these questions with our tool. In case you haven't had these problems yourself, I think you aren't our target audience as you pointed out :)

Web UI vs SSH is hardly the problem. More often, it's setting the environment set up on the remote server that's a terrible pain, then you have to set up domains and ssl and all that nonsense.

TL;DR configuration is pain to do manually every time, I hope you can make it go away. If you have ideas, comment below.

It's not only the ui. The reason why we build deploydo is that we needed to have a transparent deployment process which can scale up to 30 servers.

We wanted to be able to see what was deployed to which servers and when. Just like your github newsfeed.

Another goal we wanted to archive is confidence: We wanted a process where we can clearly see everything which will be changed on the server, therefore we implemented line-by-line diffs between the server and the repository.

These things were the real pain in our process.

I'd really like you to make a case for why I, as somebody who won't store production credentials in my code repo, should feel good storing them in yours.

I run the a SaaS cron monitoring service (Cronitor.io) and we ourselves make liberal use of SaaS tools to simplify our lives and free us to focus our time on places we can add value. But I'm skeptical of storing all the things our apps need -- private keys, passwords, paths, ports and hostnames -- with you. And that doesn't even touch on the risk that if somebody compromised you, wouldn't they essentially have a key to the back door of every one of your customers? What have you done to mitigate that risk?

Aside from all that, congrats on shipping! It's an important milestone.

Currently we are working on improving our security by encrypting user data like config files. Then we would store the password for decrypting these data on the client. We would only decrypt these things when required (e.g. when deploying). Note that this is currently only a concept and not implemented yet.

Otherwise the same applies to GitHub: If GitHub gets hacked, your application details will also be compromised.

> Aside from all that, congrats on shipping! It's an important milestone. Thanks :)

> Otherwise the same applies to GitHub: If GitHub gets hacked, your application details will also be compromised.

Right, which is why you don't put your credentials in your source code on Github. This is common practice and one you seem to accommodate in your product, so I know you're very familiar with it...

I hope you guys are transparent about these sort of things, it will mean a lot to your adoption rate I think. A lot of people out there who could be interested in a tool like this if they felt comfortable with the security implications.

I see. How are you different from these services?:

http://dploy.io/ http://beanstalkapp.com/features/deployments

I'm not trying to attack you or anything, just trying to understand how the product fills an unmet need.

Thanks for asking this, it's a valid question. We differ from dploy.io in the following points:

- we provide true line-by-line diffs between the remote server and the deployed code, other deployment platforms only provide diffs by running `git diff`. This will help you to see if some files got edited on the remote server, e.g. for applying a hot fix.

- we only deploy files that have really changed, therefore we save traffic if you have big project

- we are faster (see http://t.co/IQM85FTa1D)

- our deployment process uses symlinks to avoid any downtime. Therefore we can also rollback very very fast. Other deployment providers don't use symlinks and upload files one by one, therefore leading your application to an unstable state because file A got already updated but file B is not yet on the newest version.

- we are very stable. If something goes wrong during the deployment your users won't be affected because we only update the symlink at the end of our process, and only if everything before exited without errors (exit code == 0)

The PHP Laravel framework have something similar with [Forge](https://forge.laravel.com/), but it is catered to the framework.

It is almost like a PAAS As A Service.

You can have the CI system setup the entire environment using something like Packer to create an AWS image and CloudFormation to deploy it.

from the features page:

> You can deploy nearly any programming language with our tool that works by just transferring the files

Maybe I misunderstand something, but this sounds like it trivializes the complexities of a typical deployment process. Services need to be restarted, code updated, database migrations run and so on...

I think for it to be successful you need to figure out a way to make automating those fragile deployment steps easy (and solid). This is a problem lots of configuration management tools are trying to solve (chef, puppet, ansible, fabric, capistrano etc). Or at least help integrate deploy.do with such tools.

We provide hooks in our deployment process which you can use to do these kind of tasks. E.g. if you have to restart your web server after your deployment you will typically add something like `sudo service httpd restart` into the hook.

If you have a really complex deployment process and need more than just our hooks we are not the right tool for solving your problem. But for your typically php or rails application you will be happy with deploydo :)

"Ever asked yourself why deploying your projects to your servers is such a pain?"

I know exactly why it's such a pain. Because every deployment tool available only deals with the easy parts.

Yes, I want to use a web interface like this, and the config management feature is something that I would find very useful.

No, I'm not comfortable giving a third-party service SSH access to our servers. Besides, all of our machines are on a private network behind a VPN. This is a best practice that most, if not all, companies should follow.

We can understand your point. You have to trust us like you have to trust your server hosting provider.

It is really worth having a .do domain? given that they are fairly expensive and seems like google will treat them as specific from Dominican Republic and not generic[1]?

[1]https://support.google.com/webmasters/answer/1347922?hl=en

"shinny" should be "shiny" on this line:

We will do the rest for you. Just look on our shinny loading indicators while we are deploying your code without any downtime!

Thanks for pointing this out, just fixed this.

Also: Start using deploydo in 5 minutes, completly [sic] free!

Thanks, fixed.

There's a lot of explanations of source code deployments, but it never mentions compiled binaries. Is it capable deploying build outputs?

It would be possible to deploy your binaries but in this case you have to rebuild the whole project on each server. If you have long build times, deploydo is not the right tool for the job.

This is difficult for some setups, as it relies on an open SSH port. Our AWS instances are not publicly accessible, so this makes it hard.

Why not just use ansible?

>You just provide us login credentials to [your] server ...

This type of comment is now highly discouraged on Show HN posts. Please post only constructive negative comments, or if you don't have any - rather choose to not comment at all.

Reply on news.ycombinator.com