[HN Gopher] Piku: Allows git push deployments to your own servers
___________________________________________________________________
Piku: Allows git push deployments to your own servers
Author : tosh
Score : 537 points
Date : 2024-06-09 07:40 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rcarmo wrote:
| Very happy to see this here - check out our freshly revamped docs
| at https://piku.github.io/
| stavros wrote:
| Is this the successor to Dokku? I didn't know you had a second
| project.
| rcarmo wrote:
| Nope, just took inspiration from it because I couldn't run
| Docker on some of my targets.
| ewalk153 wrote:
| Great to see the updated docs.
| pixelmonkey wrote:
| The new docs look great!
| stavros wrote:
| This looks good, and Dokku has been very solid for me, but
| removing the Docker dependency means that now I'm beholden to my
| OS's choices. For apps that might run for years without
| maintenance, that's not ideal, as you'll quickly find you need a
| specific version of the OS for them.
| rcarmo wrote:
| You can use docker with it - I have a couple of things with
| "docker run" statements in the procfile, but of course it's not
| designed for that.
|
| Most of the deployments I got wind of are on extremely stable
| distros - typically LTS versions where you will not need to
| upgrade your runtime every six months (and my website has been
| running in it for at least two Ubuntu LTS releases...)
|
| But you can trivially use pyenv/nvenv/etc. by just setting
| environment variables. My home automation system now needs two
| different Node versions, and I have one set per app.
| stavros wrote:
| Oh yes, I definitely use LTS distros, but my longest-running
| apps are from 2008, so even LTS won't cover that.
| lathiat wrote:
| At -some- point you actually need to update things. If
| you're using a 2008 docker container you have all manner of
| bugs and security issues.
| szundi wrote:
| But at least the attack vectors are limited
| vault wrote:
| yes, limited to those that work 100%!
| poincaredisk wrote:
| I agree. But 2008 is old enough that exploits may be lost
| in time. I recently pentested a client, and had great
| problems connecting to an old service still using SSL (i
| think it was 2.0). Every modern tool straight up refused
| to connect, there was no method to override that, oldest
| static curl binaries i could find were still too new, I
| couldn't easily compile curl from source because
| dependencies also changed in the meantime. Finally I've
| found sn acient docker image that worked.
|
| The service was ironically so old that no modern
| vulnerability scanner or programming language would be
| able to connect!
|
| This made me seeiously ponder the fleeting nature of
| modern world - SSL support was everywhere 15 years ago,
| and now I, as an expert, had great problems using it.
| What chance do we have in 100 years?
| layer8 wrote:
| That depends on your tech stack. I have Perl CGI and Java
| apps that have been running unchanged for two decades. And
| the only thing I ever _had_ to change on Debian over that
| time was adding HTTPS (Let 's Encrypt) and SPF/DMARC for
| email.
| stavros wrote:
| Yeah, but my point is that you have to upgrade your OS.
| If you never change anything, obviously you don't need to
| worry.
| layer8 wrote:
| My point is that OS upgrades don't have to break tech
| stacks, and don't tend to with runtimes that care a lot
| about backwards compatibility like Perl and Java. I did
| regularly upgrade Debian across those two decades.
|
| IMO that quality should be the default, and I would
| choose my OS and tech stacks accordingly.
| stavros wrote:
| Don't they link against static libraries? How do they do
| that?
| layer8 wrote:
| The runtimes are part of the Linux distribution and get
| upgraded along with it (and receive continuous security
| updates along with it), while maintaining backwards
| compatibility for the application code (Perl scripts or
| Java bytecode). Tools like _needrestart_ will notify when
| a process needs to be restarted to take advantage of the
| update.
| stavros wrote:
| Ah, all your dependencies are in the language you're
| using? Some of mine use dependencies that are written in
| compiled languages.
| layer8 wrote:
| Not necessarily, but they are part of the Linux
| distribution.
| stavros wrote:
| Well, I don't know about you, but my dependencies have
| often been built against a static library from a
| different version of the OS, so they wouldn't work on
| mine.
| keredson wrote:
| OS updates are important sometimes. Security and all...
| kybernetikos wrote:
| I use nix via jetify devbox. Maybe something like that could
| help here.
| stavros wrote:
| Nix would actually be fantastic for this, but I've never been
| able to get it to work (including with Devbox and a few other
| such solutions). I might try again, thank you.
| tym0 wrote:
| A different niche than Piku but I will give Dokku another vote.
|
| I've upgraded my dokku install over 3-4 Ubuntu LTS so far and
| it's been problem free for my use case of hosting little side
| projects on a VPS.
| schneems wrote:
| Have you tried cloud native buildpacks? I posted a link to a
| tutorial on the top level.
| Sammi wrote:
| Sometimes docker is overkill and I'm so glad something exists
| that doesn't require it.
| yard2010 wrote:
| Question - how can dependency hell be solved when using such a
| tool?
|
| It seems so elegant and I love the "it just works" attitude,
| and I do understand that docker can't be used everywhere due to
| its technical (and mental) overhead, but I love it because it
| allows to isolate everything, freeze everything in time so
| running a container 5 years for now "just works".
|
| In my humble workflow, I'm using lazydocker to manage the
| containers, gitlab workflow (action?) for deployment on push
| and a small VPS to build and push the containers to gitlab
| registry and to run it, on the same VPS. It's a little bit
| overkill - I could use a combination of a Dockerfile and a
| compose.yml with docker compose build. Also, I didn't figure
| out scaling yet. Good thing I don't need it! Otherwise I would
| swap docker for k8s and lazydocker for k9s.
|
| (I'm open to suggestions. I just got into devops, and I love
| it!)
| myaccountonhn wrote:
| Personally I use the same approach to piku, but instead
| rebuild my Nixos config on push. My projects use nix flakes,
| so I get both something that I know will run on my server and
| on my local machine with the full development environment. No
| containers needed technically, but I use systemd nspawn to
| run the software in its own sandboxed namespace.
|
| My entire server is then managed declaratively, so if I want
| to add a new project, it's like 3-5 lines of Nginx config and
| push, that's all. Something goes wrong? Just revert the
| commit.
| ku1ik wrote:
| This sounds super interesting! Do you have an example of
| such a config somewhere, that you can share?
| myaccountonhn wrote:
| I did a write-up of setting up nixos with git deploys
| here: https://mccd.space/posts/git-to-deploy/.
|
| As far as the nixos config is concerned, there is nothing
| crazy in it. It is just a regular nix config with nginx
| (https://nixos.wiki/wiki/Nginx). You can see there that
| adding nginx is just four lines of code, ~eight with ssl.
| Use it to proxy to your applications that are setup as
| systemd services
| (https://wiki.nixos.org/wiki/Systemd/User_Services).
|
| Edit: btw I'm a big fan of asciinema! ty for making it.
| :)
| sureglymop wrote:
| I use docker compose + traefik. It's nicer than dokku for me
| because there are less magical abstractions.
| mati365 wrote:
| Isn't it better to create local docker repository and then use
| Podman Quadlet with autopull images to run apps?
| pacifika wrote:
| Better in what way?
| mati365 wrote:
| 1. Less dependencies (only Podman and registry is needed) 2.
| Rock solid rootless systemd service management 3. Easy
| integration with systemd-proxyd 4. Easy manage dependencies
| between containers (with healthchecks) 5. Rollbacks
| GordonS wrote:
| Sounds interesting! Is there any support for multi-node
| systems? Let's say I want to have an ingress Caddy proxy on
| one node, which reverse proxies to several backed APIs on
| other nodes - can this be done simply with Podman Quadlet?
|
| Also, what is the localdev UX like? With Docker Swarm I can
| easily run very similar setups in dev, test and prod, and
| it works with multi-node setups, has support for secrets
| etc. But the lack of work going into Docker Swarm becomes
| more concerning as the years pass by.
|
| Also, had no idea systemd-proxy was a thing - is there
| anything systemd doesn't have its tentacles into? :)
| mati365 wrote:
| If your VPS is wired with another one using VPC or any
| other internal network it'll just work. Just point Caddy
| to specified internal IPs of your other servers.
|
| It's not designed to work on local envs. When I wanted to
| debug infra I used to run it on Vagrant though
| altairprime wrote:
| Does this all fit in 256MB of server RAM?
| rcarmo wrote:
| You can't do that on tiny systems very easily.
| ericaska wrote:
| pikku means tiny or little in Finnish. Is it where the name came
| from?
| cuu508 wrote:
| I don't know but my first association was "pico-dokku"
| ewalk153 wrote:
| My guess has been they both originate from heroku; docker
| heroku to dokku, pico heroku to piku
| rvnx wrote:
| Cute, as in the sibling language, Estonian it means "big" or
| "tall"
| rcarmo wrote:
| Nope. https://piku.github.io/FAQ.html
| theanonymousone wrote:
| Nice work. But why isn't Docker supported as a runtime? Or is it?
| rcarmo wrote:
| The FAQ explains it: https://piku.github.io/FAQ.html
|
| You can use docker run commands, but that's not the main goal.
| sneak wrote:
| I think a more common use case than doing deploys by pushing to a
| different remote is to send git repo webhooks on PR merges to
| main to an API that has a deploy key and can fetch the repo
| itself.
|
| This afaik is missing from most PaaS tools (CapRover excluded,
| but it has been illegally relicensed to non-open-source). Perhaps
| watchtower or something could replace the functionality?
| adeptima wrote:
| Didnt know ...
|
| "CapRover has built in anonymous usage analytics starting
| v1.11"
|
| https://github.com/caprover/caprover/blob/master/TERMS_AND_C...
|
| https://github.com/caprover/caprover/issues/1852
|
| Was looking at CapRover to see if it has REST API
|
| Looks shaddy
| vault wrote:
| You scared me for a moment, as I've just setup a new VPS with
| CapRover and migrated all my projects from heroku. Doesn't
| look too shady for me, there's a oneliner to disable
| analytics, it seems enough for me.
| sneak wrote:
| You still have to agree to the terms and conditions of use
| of the nonfree application which can of course change at
| any time without notice. It's a time bomb.
|
| I'm thinking of forking it and adding all his dumb and easy
| table stakes features (2fa etc) that he is trying to gate
| as subscriptionware.
| rcarmo wrote:
| If you want to contribute any of that to piku, we'll
| welcome it. Might take a bit to review and merge, but
| we're always looking for non-breaking improvements
| sneak wrote:
| It's not even open core. The solo maintainer simply
| relicensed the entire repo to a nonfree license without
| consent of the copyright holders to all the external
| contributions.
| rcarmo wrote:
| Actually, this is how I deploy my static websites: piku in lazy
| mode handles GitHub hooks, pulls the source and renders them
| out to cloud storage, then kills all workers and idles again.
| foxhop wrote:
| are there docs for this setup?
| rcarmo wrote:
| It's just a 10-line script, I'll see if I can sanitize it
| and add to the docs (one of the samples already does
| something similar, you can peek at the repos to get ideas)
| sneak wrote:
| Does it support deploy keys, or are your website source repos
| public?
| rcarmo wrote:
| The piku micro-app that does the deployment is just a
| 10-line Bottle app that validates the GitHub hook and does
| a git pull with a private SSH key, so yes.
| block_dagger wrote:
| Cool project, but I'll stick with Dokku, which is a wonder for
| managing single server deploys via Docker/Git.
| demarq wrote:
| Is there support for secrets?
| rcarmo wrote:
| You have to bring your own. I have some trivial deployments
| that fetch secrets from Azure keyvaults using either release
| hooks or app startup code.
| demarq wrote:
| Thanks
| dakiol wrote:
| Does someone know how it handles (if any) zero downtime
| deployments? Like, if your Python service is running in one
| machine on port 8080 behind nginx, how does piku switch to a
| fresh instance running in the same port?
| rcarmo wrote:
| Currently it will only kill running processes after it finishes
| deploying the new git push. Socket and session handling will
| vary depending on your code and whether you use uwsgi or run
| your own HTTP daemon.
|
| One thing it already does (optionally) is to kill off unused
| instances and idle, lazily starting them when a new connection
| comes in.
| mrweasel wrote:
| Slightly off-topic, but you can do zero downtime deployments
| using systemd and socket activation.
| rcarmo wrote:
| That gives me a couple of ideas...But picking a shorter name
| than "piku" is going to be hard... Maybe I can whip up a
| proof of concept and call it "syd".
| pixelmonkey wrote:
| I love piku. I wrote a webapp tutorial for piku which got turned
| into a repo as part of the official GitHub piku org. You can find
| that here:
|
| https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
|
| It explains how piku works under the hood, as well as showing a
| minimalistic Python web app example from a user standpoint.
| rc_kas wrote:
| "What is a Heroku-style deploy?"
|
| thanks for that. I have no idea what heroku is or does.
| pixelmonkey wrote:
| Sure thing! Bit of cloud computing history. Covered a bit
| here:
|
| https://leerob.io/blog/heroku
| jslakro wrote:
| Basically it was the first PaaS to improve the developer
| experience when working with server infrastructure. It had
| git integration and allowed to scale easily your apps from a
| CLI
| brightball wrote:
| Short version:
|
| Git push deployment where it detects your stack and
| automatically builds, then deploys with zero downtime.
| sesm wrote:
| Thanks for the explanation, official repo doesn't make it clear
| enough for me.
|
| So, did I understand correctly, that Pico installs both an
| agent on the remote machine and a commit hook on the local
| machine? Why didn't they minimize the overhead by just making
| the remote machine a Git remote and do all the work there when
| you push a specific branch to that remote?
| pixelmonkey wrote:
| piku installs an agent on the remote machine (piku.py) which
| itself also provides the support for making that machine a
| git remote.
|
| There is no commit hook on the local machine. On the local
| machine, you simply have a shim named "piku" which is
| essentially running "ssh remote /path/to/piku.py $@" to
| control the remote machine.
| sesm wrote:
| Thanks for clarifying!
| rcarmo wrote:
| You're confusing things, there is only the remote, the local
| machine doesn't need anything. We do have a simple CLI you
| can run locally, but all it does is ssh remote <command> to
| scale up/down workers, change settings, etc.
| sesm wrote:
| Thanks for clarifying!
| yodon wrote:
| The new piku docs are pretty but, as a potential new user very
| interested in trying piku, the new docs are completely useless
| to me. I gave up on piku because the docs essentially assume I
| already know everything I need to know to run and use piku.
| Your doc fixes that, but I never found your doc even after
| spending quite a bit of time trying to figure out how and
| whether I could use piku. I never would have known it existed
| without your comment here.
|
| At a minimum, your doc should be prominently linked to from
| both the piku repo and the piku docs (or more prominently
| linked, if it's already linked somewhere), if not pulled
| completely into the docs home page.
|
| That said, if you're interested in a suggestion, take a look at
| an end-to-end coolio tutorial that shows how to go from new
| bare metal server to publicly accessible custom domain name
| with SSL cert, and add the extra steps to your doc (even though
| yes, they have nothing directly to do with piku, because they
| have everything to do with what a potential new user actually
| wants to do and the potential new user doesn't know how to do
| those steps yet even though you do).
|
| Your doc is already hundreds of times more useful than the main
| piku docs page. Extending your doc to cover an example of how
| to get to exposing a publicly accessible custom domain with SSL
| cert would make your doc hundreds of times more useful than it
| is now. Yes, I know, there are a ton of ways to get from where
| your doc ends to a publicly available custom domain with SSL
| cert. Pick one. It doesn't matter what you pick. The person who
| cares which approach you use already knows how to do the
| approach they prefer. You're adding these steps for the person
| who doesn't know how to do any of the anpproaches and just
| wants to get to their site hosted on a $5 droplet or whatever.
|
| Again, your page is a huge help, this suggestion is just about
| making your page a huger help.
|
| For reference, here's a sample coolio end-to-end example
| showing how they go from bare metal to publicly accessible
| custom domain with SSL:
|
| https://billyle.dev/posts/self-hosting-your-website-with-coo...
|
| The goal of all this isn't about making it possible to do
| things, it's about massively increasing the number of people
| who adopt piku by making it easier for more people to do so.
| rcarmo wrote:
| Acknowledged. The tutorial is linked someplace deeper in the
| docs, but I am adding a direct link to it in the docs home
| page. Should be up in a little while.
| rcarmo wrote:
| This is now linked from the docs home page.
| isoprophlex wrote:
| That is brilliant. Something complex, but not complicated. A
| project distilled down to its UNIX essence: hackable, lean, and
| magic.
|
| That said I want to give this a go but don't immediately see how
| I can migrate my overengineered 8-10 container spaghetti of a
| docker-compose file to a state where I can use piku instead of
| manual 'git pull && docker compose up' on the remote
| rcarmo wrote:
| That kind of situation was what drove me to go simpler :)
| isoprophlex wrote:
| Yes it's me, not you ;)
|
| Currently hyping myself up to drastically simplify
| everything, which will be a joy onto itself
| nanidin wrote:
| Can't you use git hooks to automate the manual steps?
| cfiggers wrote:
| The initial commit was _eight years_ ago??
|
| I wish I had known about this project ~18 months ago. I was
| specifically looking for a way to have a Heroku-like dev
| experience deploying to my Raspberry Pi, and this looks like it's
| trying to be exactly that.
| vault wrote:
| Exactly. There's a visibility problem. I've just setup a new
| VPS with CapRover and never found any mention of piku in the
| hour I've spent checking for comparisons between "Heroku-style
| self-hosted PaaS" dokku, CapRover, coolify, and dokploy.
| rcarmo wrote:
| We've been using it for a long time, yes, but doing Marketing
| for a 1500 LOC Python script felt a little overblown :)
|
| Still, Chris did a public presentation on it near the
| beginning (video's in the docs) and other folk did similar
| things, so...
| aaomidi wrote:
| Is go support planned?
| rcarmo wrote:
| It works with Godeps. Module support was always a bit in flux
| when we added that, but it should be an easy first
| contribution...
| brigadier132 wrote:
| These self-hosted open source paas alternatives are really cool.
|
| Off the top of my head I know of
|
| coolify dokku kamal
|
| and now piku
| vault wrote:
| Don't forget CapRover. I'm just trying it on a new VPS and it
| just works as expected. I would have tried piku first if I knew
| about it, because it's even more minimal.
| p-o wrote:
| First time I read about piku. I have no idea why, but the feeling
| of `git push` to initiate a deployment like piku does always felt
| magical to me. There's nothing simpler than that.
|
| This is timely for me as well as I just open sourced (yesterday!)
| a project that is in the same space, but for Kubernetes
| (https://github.com/pier-oliviert/sequencer).
|
| All of this to say, congrats! It looks great.
| CaptainOfCoit wrote:
| Maybe I'm missing something obvious, but how does sequencer use
| git to do deploys, if it's similar to Heroku/dokku/piku? Seems
| like you're dealing with kubernetes templates and kubectl
| rather than `git push` to deploy, which would put the project
| is a completely difference space.
| myaccountonhn wrote:
| It works like magic, but it's also extremely simple to DIY if
| you wanna learn.
|
| If you set up a server, you can create a git repo by just doing
| `git init --bare`, add the setting `git config
| receive.denyCurrentBranch updateInstead`.
|
| After that you can use git hooks (more specifically push-to-
| checkout hook), to receive uploads, compile and launch. The
| hook will just be a simple shell script, the most basic version
| could be a variant of `compile && install && systemctl restart
| service`.
|
| From there you'll be able to copy the repo locally and pushing
| your changes will now trigger the hook you've setup.
|
| git clone root@yourserver.com:/path/to/git/folder
| rcarmo wrote:
| You just described Piku, except that it's a Python script
| that also sets up nginx and a process supervisor for your
| code :)
| myaccountonhn wrote:
| Yeah I love the simplicity of Piku, being able to actually
| understand what is happening behind the scenes is a great
| quality. :)
| tasuki wrote:
| I've been doing almost exactly this. Have set up Ansible to
| automate it.
|
| Why would I want to use Piku? Would it give me some benefits
| I currently don't have?
| zeroq wrote:
| 15 years ago it was common to deploy web applications as live SVN
| repositories with a hidden path executing 'svn update' on manual
| http request.
|
| Not quite the 'push deploy', but that was the way apps were
| developed back in the days, and for some reason I still prefer
| that approach. Commit, test, and at one point manually nominate
| and deploy stable version.
| eastbound wrote:
| Yes, when we didn't want a build machine, we'd just build in
| production. Isolating production with no unauthorized binary
| (like Alpine) was a long path away...
| rmbyrro wrote:
| You can do that in the git push by having a separate "stable"
| branch and linking deployment to it.
| tiffanyh wrote:
| With PHP, 1-line (no new tools): sftp user@host
| remoteFile localFile
|
| Joking aside, I'm a bit surprised such a tool would be developed
| in Python given its dependency's and runtime (which is not easy
| on the user).
| rcarmo wrote:
| To be honest, Python made it stupendously simpler than anything
| else because it has a great standard library. The only
| dependency (click) is rock solid and made it a lot simpler to
| handle commands independently, but we could probably do without
| it and just use the built-in argparse---but at the expense of a
| few more lines of code I didn't want to maintain.
|
| Also, Python is everywhere, on every OS and Linux system, so it
| was a natural choice. I also wanted it to be easily hackable
| and extensible, and few languages would make it simpler to
| understand or extend.
| mlhpdx wrote:
| That's pretty funny. You may want to look a little further
| field to discover that the machines with Python are far from
| "all the machines" out there. Particularly production
| servers, which, if they run responsibly, are hardened with
| every extraneous bit of software removed.
| jteppinette wrote:
| I developed security software in Python that ran on 100k+
| production nodes covering dozens of operating systems. They
| all had Python.
| hamandcheese wrote:
| Counter-anecdote: none of my Linux PCs have python.
| jteppinette wrote:
| Counter-counter-anecdote: my toaster has python.
| BbzzbB wrote:
| Debian comes prepackaged with Python. If there are
| distros that are good enough for a server almost out of
| the box, surely Debian stable is one.
| skeledrew wrote:
| Not sure who's to "blame", but I was super surprised a
| few days ago when I installed Kubuntu 24.04 (minimal),
| and Python was missing. Was fine though as I strictly use
| via pipx and miniconda only, but still surprising.
| zie wrote:
| I used to run Python 2 on OpenVMS in production. Python can
| have a pretty wide footprint if one looks around.
| pixelmonkey wrote:
| It's actually worth taking your joke seriously to compare and
| contrast:
|
| - piku deploys via git rather than scp/sftp, but authenticates
| via ssh like those tools
|
| - piku supports a number of runtimes, including Python, Ruby,
| Node, Go, Clojure. The runtimes are implemented rather simply,
| you can add your own rather easily, see examples here in the
| code:
| https://github.com/piku/piku/blob/8777cc093a062c67d3bead9a5d...
|
| - For each runtime, a mechanism is utilized to install and
| isolate package dependencies (requirements.txt in Python,
| Gemfile in Ruby, packages.json in Node, etc.)
|
| - a Procfile and ENV file are used to declare your application
| entrypoints and envvars akin to Heroku / 12 Factor App ideas
|
| - a CLI (ssh shim on dev client machine) is provided for
| checking status and logs from the client (as well as
| stop/start/restart)
|
| - since all applications are managed via uwsgi on the remote,
| there is also support for worker/sidecar processes and cronjob-
| style scheduled tasks
|
| - HTTPS via Let's Encrypt (acme.sh) is handled automagically
| for web apps
|
| I describe more about how piku works in this tutorial:
|
| https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
|
| You're right that PHP apps have a simple deployment story, and
| in a way piku brings something akin to this level of simplicity
| to other web programming runtimes.
| rozhok wrote:
| You still need to install nginx, php-fpm an configure certs, so
| php is not that easy unfortunately.
| BryanLegend wrote:
| What is a PaaS?
| snitty wrote:
| Platform as a Service.
|
| Which leaves me the same number of questions.
|
| So, what is Platform as a Service?
| rcarmo wrote:
| Maintainer and co-author here. If you like simple, minimalist
| deployment tools, check out https://github.com/rcarmo/ground-init
| for a very much down to earth take on cloud-init...
| e12e wrote:
| Your readme doesn't really answer the question of why not
| cloud-init?
| rcarmo wrote:
| You can't use cloud-init on already installed systems.
| red_admiral wrote:
| Eventually, we'll need something more secure than effectively
| `sudo curl INSTALLER | sh` as a way to install stuff. I can see
| why package managers aren't always the answer, but still.
|
| piku itself is neat and I like it.
| rcarmo wrote:
| Actually, we had manual install steps as the only way to go for
| a while. You'd be surprised at how many people asked for a one-
| liner... I'm going to add a note to the docs about that, since
| I've seen a couple of comments here of people who were put off
| by it and didn't even read the rest.
|
| I actually only install piku via cloud-init, but there are
| plenty more options: https://piku.github.io/install/index.html
| wayoverthecloud wrote:
| Has anybody used this for Ruby on Rails?
| rcarmo wrote:
| Yes. Not any of the maintainers, though.
| nico wrote:
| Can it be a good replacement for Capistrano (for deploying rails
| applications)?
|
| Love the focus on being lightweight
|
| Recently I wanted to create a super basic website, and discovered
| it's actually pretty hard to create something simple
|
| And then, even if you manage to create something actually simple,
| you usually end up having to manage some not so simple deployment
| process together with hopefully some sort of version control
|
| Ended up settling for putting plain html/css/js files in a git
| repo, then configuring auto deploy to GitHub Pages on merge to
| master (via Actions)
| juliushuijnk wrote:
| Also an option, if it's just for you and with not too many
| updates, you can upload the new files to ftp as a manual step.
| nico wrote:
| Does GitHub pages support ftp? Or are you talking about some
| other potential hosting options?
|
| Yes, ftp is pretty easy for static sites. However, given I
| want to have version control, it's nice to have automated
| deploys happen after a git push
| mati365 wrote:
| Use Podman Quadlet, I use it as replacement
| verisimi wrote:
| But what if you like 'big pass'?
|
| Looking at you sir mixalot:
|
| https://youtu.be/wKfMZOR8eWI?t=31
| kachurovskiy wrote:
| I just added a magic URL in my app that GitHub calls whenever a
| commit is pushed and the server does `git pull` which in turn
| causes pm2 to reload the app. So committing anything shows up in
| production in seconds. Great for smaller projects.
| fprotthetarball wrote:
| I have a similar setup, using snare to handle the webhook
| endpoint: https://github.com/softdevteam/snare
|
| GitHub will call the webhook after a push to main and a
| successful test suite run. Snare runs a shell script on my
| server to git pull, build, deploy, and call a cronitor.io hook
| for monitoring deploy success.
|
| I've been pretty happy with how relatively simple it is and how
| well it works.
| gitinit wrote:
| How did you set this up? Seems simple yet effective.
| pheggs wrote:
| interesting project! what are the advantages of this over pushing
| to a normal ssh server with a server side git hook?
| acidburnNSA wrote:
| Came to ask this same question. I have a post-receive hook on
| my server that instamagically deploys whenever I push to it. It
| is simple and awesome and is basically just a builtin git
| feature.
| eloh wrote:
| I just "git push" using nixos-rebuild
| schneems wrote:
| Not related to "git push" deployments, but absolutely related to
| the PaaS experience, the team I'm working on is previewing Cloud
| Native Buildpacks (CNB) which is an open spec in the CNCF for
| Buildpacks that target OCI.
|
| What this means is that you can now generate a docker image
| locally using similar build tooling to Heroku's "git push" logic
| that detects language support and does the right thing TM. Here's
| a tutorial for building a Rails app with the buildpack I maintain
| https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...
|
| Would love some feedback, if you try it. Please consider posting
| about the experience in the linked discussion (good, bad,
| indifferent, or whatever I just want more feedback to improve the
| experience).
| Alifatisk wrote:
| Repeat after me: git, is, not, a, deployment, tool
___________________________________________________________________
(page generated 2024-06-09 23:00 UTC)