[HN Gopher] Deploy from local to production (self-hosted)
___________________________________________________________________
Deploy from local to production (self-hosted)
Author : bypirob
Score : 60 points
Date : 2025-03-08 18:54 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| barrettshepherd wrote:
| What's the advantage of this over Kamal? (https://kamal-
| deploy.org/)
| ngrilly wrote:
| I like that it's a single file executable. But Kamal offers
| much more, for eample zero-downtime deployment.
| oulipo wrote:
| Also Dokploy, Dokku, Coolify and similar
| indigodaddy wrote:
| This seems cool and all but it's fairly trivial to docker compose
| whatever stuffs/apps you want and install caddy as the reverse
| proxy on the host (I normally don't do caddy in a container but
| it might be better to)
|
| You have to setup docker compose files with airo it looks like in
| any case, so this just simplifies the caddy part? But caddy is so
| simple to begin with I'm not sure the point..
| ratorx wrote:
| Does it even configure caddy? I can't see how the caddy config
| could be generated from the env.yaml (unless it relies on the
| directory name etc for the path).
|
| Seems like something that could have been solved with just
| docker compose (by setting a remote DOCKER_HOST). If you need
| "automatic" proxying, then traefik can do it off container
| labels.
| timdorr wrote:
| Nope, it just copies over a hand-made Caddyfile and restarts
| a docker container that you need to already be running: https
| ://github.com/bypirob/airo/blob/1a827a76f2254e5ca4f4ba4...
|
| This looks extremely barebones and makes a large number of
| assumptions in its current state. This is better as a Show HN
| after some more dev work has been completed.
| delduca wrote:
| Docker compose + Cloudflare Tunnels is my current setup, no
| need to deal with SSL, have a public IP address, and if you
| make use of Tailscale, you do need any open ports, witch is
| extremely secure and robust.
| zelifcam wrote:
| Imagine if people just used the tools themselves instead of
| creating yet another layer in hopes of simplifying something that
| can already be done with a few lines on a bash script.
| cdfuller wrote:
| Agreed. This project isn't that upfront this is a wrapper
| around 4 commands. Docker build, docker push, docker pull and
| compose up.
| morcus wrote:
| For small projects you can also add something like Watchtower
| to your compose file and then you need only build and push
| the image.
|
| And I assume you want to be building once to test your
| changes anyways, so you really only need to push.
| MyOutfitIsVague wrote:
| Whew, you're not joking. This whole thing is 156 lines of Go.
| I'd probably have just used a shell script for this kind of
| thing.
| 0xbadcafebee wrote:
| I think we can all agree that any Go program that just
| executes some other program, is way better than a shell
| script!
|
| I mean, what if you needed to change the way it worked?
| With bash you'd have to open a text editor, change a line,
| and save the file! And on top of that you need to
| understand shell scripting!
|
| With Go, you can set up your development environment, edit
| the source code, run the compiler, download the external
| dependencies, generate a new binary, and copy it to your
| server. And all this requires is learning the Go language
| and its development model. This is clearly more advanced,
| and thus better.
| xandrius wrote:
| Exactly, for over 4 years I've been using my trusty 10 lines of
| bash (most of them is confirmation) to deploy in seconds and
| with 0 downtime. I should probably opensource it, lol
| Wilduck wrote:
| I know you're joking a little, but I personally would love to
| see them! I'm very interested in how people manage simple
| deploys.
| polishdude20 wrote:
| My method is I push my code to master and then ssh to my
| server, git pull and restart the server
| mediumsmart wrote:
| I use rsync in a script. One line builds and the second line
| deploys - but that pushes to a server someone else has standing
| on the ground with a disk in it that hosts the site I myself made
| on a local machine. If I self-hoist the production server into my
| flat, couldn't I just copy the folder without the internet like
| from local to local?
| rad_gruchalski wrote:
| No need to even copy a folder, simply link it.
| scottydelta wrote:
| I have been using coolify on a bare metal server and it has been
| such a great experience.
|
| The ability to spin up services is crazy good and easy. I was
| able to evaluate n8n, windmill.dev and prefect in 3 hours because
| I was able to quickly setup these clusters and test them. And
| final thing was to compile my code as docker container and spin
| it up on coolify within mins with custom domain and ssl.
|
| How is it different and eaiser than coolify kinda setup?
| jilles wrote:
| I did the same. Really enjoyed Coolify but at some point there
| was too much magic.
|
| I'm now using Dokku and can't imagine using something else.
| sameklund wrote:
| Considering both of these right now. Why was Dokku so much
| better for you?
| kilroy123 wrote:
| Same here but I've certainly ran into some rough edges.
| Especially with some of the more complicated one click
| services.
|
| Overall, I like it but I wish it was a bit more polished.
| __jonas wrote:
| I've got a kind of similar setup but what I've been doing is
| instead using a registry I'm just pushing the images along with
| the compose file onto the server directly with rsync to keep
| things even simpler. Would be nice to have a proper tool like
| this to automate that (I'm just using a bespoke shell script).
| qudat wrote:
| I just use a tunnel service to self host web services, works
| great and is cheaper than a VPS: https://tuns.sh
| Nelkins wrote:
| All of these projects lack server hardening. I think for most
| devs it would not be a great idea to just point at a server and
| let 'er rip. I have a pretty extensive cloud-init script I use
| for this when deploying to a VPS. I workshopped it by finding
| existing scripts and having a back and forth with Claude. Feel
| free to roast it :)
|
| https://gist.github.com/NatElkins/20880368b797470f3bc6926e35...
| simpaticoder wrote:
| Thank you for sharing, because I didn't know what cloud-init
| was until your post. I've done something similar, but packaged
| as a library of bash functions, designed to be called in
| arbitrary order. I cannot comment on the specific decisions you
| made in your file, but the fact that a declarative, compact,
| and standard solution exists for this problem is music to my
| ears. Out of curiosity, where did YOU learn of the existence of
| this feature?
| shortsunblack wrote:
| Cloud init/Cloud config is a standard way to provision Linux
| hosts. It is slowly being outcompeted by Ignition and the
| friends, though.
| wongarsu wrote:
| There is a weird dynamic going on where defaults have become
| "good enough": ssh with public key configured and password auth
| disabled, services defaulting to only listening on localhost,
| etc., but those improvements have also cause people to pay much
| less attention to server hardening or to checking if any of
| their services might have unsafe defaults.
|
| The world is made much better by safer defaults, but they also
| lead to a degree of complacency.
| fragmede wrote:
| port 22 and usepam is interesting. maybe set that to not 22 and
| not use pam unless you have a specific reason to. didn't dig
| deep to see if you had one but you're not setting a pam.conf.d
| file as far as I saw. There's more to pick apart, but if that's
| the best Claude can do my job is safe for 30 more seconds.
|
| hire a professional to secure your shit.
| notarealllama wrote:
| Thanks for this, I still provision with a bash script.
| Wilder7977 wrote:
| I had a quick look, that "deploy" user can run any sudo command
| without password? It's basically root at that point. I think
| that forcing a password (maybe using some lax timeout if you
| don't want to insert it so often) is a much better option.
| Correct me if I am wrong, but I also see that there are secrets
| in the file (e.g., gmail SMTP creds). Make sure the file is
| protected in read at a minimum. If those are your gmail app
| credentials, they are pretty serious and obtainable by just
| reading the file (same goes for postfix config).
___________________________________________________________________
(page generated 2025-03-08 23:00 UTC)