It uploads your whole local docker context, source code and all, builds the image on the remote server and up's the container(s) all with a single command. I use this all the time when deploying simple services to avoid all of the complexity of registries etc.
Yeah, its the same underlying functionality that Depot, Docker Cloud Build and also Offload uses under the hood to switch the context to a remote host: https://www.docker.com/products/docker-offload/
To me, it looks like this new project is aimed more at being able to develop remotely and share your localhost:3000 env instead of getting a real production box up. Bidi sync etc... hints at that, it's like having a 2-interface dev env.
I understand what you are trying to do but you should checkout dokploy or coolify.
You push to github, github action builds it and hits dokploy webhook and it pulls your github code and build and deploy on that server.
This is more reliable and industry way. What you are doing requires same amount of time to deploy and requires manual intervention every time.
For once i thought you were moving code to server and then you just restarted container and it worked without having to build. I have done it in the past due to some unique requirements where dependencies are in docker image and code is copied from local to server and docker image took code from server on start.
Not sure if you read the description but I clearly stated that I wanted no middleman, so I'm not sure how this solves my use case. Also not sure how it requires the same amount of time, and 'manual intervention every time'? You provision a remote server, install docker then update the local config file and it's done. One line deployments everytime. And why would I update the code inside the container when you need a build process to install dependencies? If you want to update code while the app is running then restart, then docker is not the right solution.
Additionally there are a million different and better ways to deploy services, this suits the use case I described.
CI/CD are used for deploying to all kind of environments. For production, the triggers are different. Instead of deploy on PR merge, you would define the trigger as tag creation.
Now when you make a release mauanlly on github, it will create a tag which in turn would trigger deployment.
I had a similar script a few years ago when I refused to give up my aging Macbook Air and built a server to host my dev env. I had an rsync command that would sync the differences from my local machine up to the remote box. It was surprisingly quick considering the size of the projects.
Here is my main use case. I have lightweight services that I need to update and deploy regularly (until I movee to K8s or a proper production env). Using pooshit, I can push my entire local dev folder to a remote server then destroy the old image, rebuild the new image and spin up a new container with one call. Your config file contains your remote config. You need nothing in between you and your remote server and it only relies on SSH and docker, nothing else, no middleman, repos, and no deployment containers running on your VM.
Useful project. Name that no reasonable company would allow IT department to use. 10 out of 10! It worked for CockroachDB. I hope it turns into a unicorn and I'm not joking about that.
I can't remember what the package was, but when I was working for "large bank", one of the npm dependencies we wanted to use had a licence file that just said 'Do whatever the fuck you want'.
Legal came back saying that it was "highly unorthodox, but approved for use"
I'm going to have to challenge you on this one. I'm not great lover of Photoshop, and GIMP does have an unfortunate name, but it is an alternative to Photoshop in the same way Gentoo is an alternative to Mac OS, you're not wrong but...
I have never worked at or heard of a company caring about the names of software, at most it's been a bit of a chuckle. Best guess is being concerned about software names is a super conservative culture thing.
I do believe you, but be honest, both of us could come up with an easy half-dozen names for software that if spoken out loud at work or triggered a filter on the network at the office would have someone explaining to HR what the hell is going on.
Neat project, but what does this do differently than docker compose with the --host flag? https://docs.docker.com/reference/cli/docker/#host
It uploads your whole local docker context, source code and all, builds the image on the remote server and up's the container(s) all with a single command. I use this all the time when deploying simple services to avoid all of the complexity of registries etc.
Yeah, its the same underlying functionality that Depot, Docker Cloud Build and also Offload uses under the hood to switch the context to a remote host: https://www.docker.com/products/docker-offload/
What!?!? This is a thing? How did I not know about this. Thanks for the share!
To me, it looks like this new project is aimed more at being able to develop remotely and share your localhost:3000 env instead of getting a real production box up. Bidi sync etc... hints at that, it's like having a 2-interface dev env.
I don't see that at all?
Is there a single line Podman alternative?
Wow - never seen that before.
Probably pretty similar except you get to just write "pooshit" instead.
Love it.
I have to say, the name is a great touch.
I understand what you are trying to do but you should checkout dokploy or coolify.
You push to github, github action builds it and hits dokploy webhook and it pulls your github code and build and deploy on that server.
This is more reliable and industry way. What you are doing requires same amount of time to deploy and requires manual intervention every time.
For once i thought you were moving code to server and then you just restarted container and it worked without having to build. I have done it in the past due to some unique requirements where dependencies are in docker image and code is copied from local to server and docker image took code from server on start.
Not sure if you read the description but I clearly stated that I wanted no middleman, so I'm not sure how this solves my use case. Also not sure how it requires the same amount of time, and 'manual intervention every time'? You provision a remote server, install docker then update the local config file and it's done. One line deployments everytime. And why would I update the code inside the container when you need a build process to install dependencies? If you want to update code while the app is running then restart, then docker is not the right solution.
Additionally there are a million different and better ways to deploy services, this suits the use case I described.
There is nothing “industry way” about letting CI automatically deploy your production environment.
CI/CD are used for deploying to all kind of environments. For production, the triggers are different. Instead of deploy on PR merge, you would define the trigger as tag creation. Now when you make a release mauanlly on github, it will create a tag which in turn would trigger deployment.
Can't wait to try and get this greenlit at work.
Better off trying to get it brownlit.
My grandma laughed at this one.
I had a similar script a few years ago when I refused to give up my aging Macbook Air and built a server to host my dev env. I had an rsync command that would sync the differences from my local machine up to the remote box. It was surprisingly quick considering the size of the projects.
How does this compare to https://www.devspace.sh/ ?
It's not based on k8s, it's just pushing your local app to a server and spinning up a conainer with one CLI call.
I don't really understand the use case and wonder if containers are the right tool here at all.
Here is my main use case. I have lightweight services that I need to update and deploy regularly (until I movee to K8s or a proper production env). Using pooshit, I can push my entire local dev folder to a remote server then destroy the old image, rebuild the new image and spin up a new container with one call. Your config file contains your remote config. You need nothing in between you and your remote server and it only relies on SSH and docker, nothing else, no middleman, repos, and no deployment containers running on your VM.
what a name! fun conversations ahead for people that want to utilise it at work!
no middlemane i like it
`docker context`?
Dumb question, out of real curiosity - is the double fecal pun deliberate?
I can't wait for version number 2 to drop
I am actually surprised how well it runs, given how solid it is
I heard there's a related app called FeeCal - help calculate all your fees.
shitty joke if you ask me =)
The joke is a deuce.
Line 1 of the readme has a poop emoji
Yes.
It's actually a triple fecal pun! Push it... poo... shit.
Useful project. Name that no reasonable company would allow IT department to use. 10 out of 10! It worked for CockroachDB. I hope it turns into a unicorn and I'm not joking about that.
I can't remember what the package was, but when I was working for "large bank", one of the npm dependencies we wanted to use had a licence file that just said 'Do whatever the fuck you want'.
Legal came back saying that it was "highly unorthodox, but approved for use"
That’s amazing. I’d really like to steal that, but not being a lawyer, I’m not sure how viable it is as an actual license.
FSF has approved it, OSI has not. Make of that what you will. https://en.wikipedia.org/wiki/WTFPL
Notes from OSI rejection board meeting
> It's no different from dedication to the public domain.
-- https://en.wikipedia.org/wiki/WTFPL#cite_note-osi-2
I believe people chose to pay Adobe subscriptions simply to avoid explaining the acronym for the GNU Image Manipulation Program in meetings.
I'm going to have to challenge you on this one. I'm not great lover of Photoshop, and GIMP does have an unfortunate name, but it is an alternative to Photoshop in the same way Gentoo is an alternative to Mac OS, you're not wrong but...
I have never worked at or heard of a company caring about the names of software, at most it's been a bit of a chuckle. Best guess is being concerned about software names is a super conservative culture thing.
I do believe you, but be honest, both of us could come up with an easy half-dozen names for software that if spoken out loud at work or triggered a filter on the network at the office would have someone explaining to HR what the hell is going on.
Perhaps not directly in a review.
Names can be troublesome though, badly named products get caught in spam filters, or blocked in some firewall blacklist.
The cockroachDB thing, was that intentional or just incidental?
good post
This is a steaming pile of SFTP. Why not use rsync or wrap it if you must?
For anyone who's interested in proper bidirectional sync check out Mutagen.[0]
[0]: https://mutagen.io/documentation/synchronization/
Because I don't want to do this: https://mutagen.io/documentation/introduction/getting-starte...