
Show HN: Deploydo – Deployment made easy - _query
https://www.deploy.do/
======
druiid
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.

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

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

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

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

~~~
_query
> 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 :)

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

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

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

~~~
_query
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 :)

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

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

~~~
_query
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 :)

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

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

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

------
drsintoma
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](https://support.google.com/webmasters/answer/1347922?hl=en)

------
zzzzz_
"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!

~~~
_query
Thanks for pointing this out, just fixed this.

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

~~~
_query
Thanks, fixed.

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

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

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

------
matejkramny
Why not just use ansible?

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

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

