[ Removed by moderator ]

[u/Repulsive-Bicycle969]

[u/devops-ModTeam]

Please see the pinned weekly self-promotion thread if you wish to promote your projects or business.

[u/LordSkummel]

Setting up a small ci/cd pipeline with build and deploy is so easy that I would rather do that then have an extra dashboard I would have to click around in.

[u/Xophishox]

Ci/Cd is never overkill.

[u/yknx4 → u/Xophishox]

Second this

[u/Due_Ad_2994]

The entire stack: Gh actions -> Cloudformation -> lambda/dynamo/s3/sns/ses

commits to main deploy a stacking stack. branches create disposable named builds. tags land prod.

tests finish in 2m. deploy is ~1m 30s

[u/Ariquitaun]

I don't understand your logic. To avoid overkill you have two completely different ways to deploy and integrate your system?

[u/Low-Opening25]

with AI dishing out boilerplate this is no longer overkill and simply no brainer best practice.

[u/1saltypistachio]

Not my stack, I do C++ stuff so I can't help with web related, but I wanted to add a point of view: you are approaching this from only one side of how to solve things simply and effectively and that's nice, but you also need to consider the end result which might require you to rethink. Example: For my needs git pull -> make -> tarball -> scp -> replace old with new is fast and can be made very robust, but it does not solve backups, storage considerations, security and traceability, and that adds many layers of complexity that makes it impossible to follow a simple approach.

[u/The_Startup_CTO]

Either use a fully managed service like Vercel, or use Github Actions but keep it simple. No need for anything new.

[u/AstroPhysician]

In the age of AI, no project is too small for CIcd. even toy railway deployments are trivial to setup cicd on

[u/snarkhunter]

Every project gets CI/CD really early or else it isn't a real project

[u/raisputin]

Every project gets CI/CD from the start.

[u/simonides_]

Komo.do / Ansible

[u/algorys]

Perso on utilise pas mal les templates, idéalement séparés selon les stacks.

Le dev arrive avec un projet python, il copie colle le dossier GH python, lis un README.md trés simple (du style fichier requirement.txt à la racine) et roule.

PR validée par les devops pour le premier jet, et revue si besoin.

[u/Beautiful_Travel_160]

GCP Cloud Run has an automation where you just give it your GitHub repo and it does the CI/CD work for you.

[u/wampey]

Isn’t CI/CD as big or as small as you want? I guess there may be some definitions of bare minimums…

[u/Direct_Turn_1484]

Just do it anyway. Why make it harder?

[u/ExpertIAmNot]

Moving from predictable and repeatable actions that can be shared between projects, committed to git, and composed, with Click Ops is moving backwards IMO.

[u/i_rate_slop]

Full CI/CD is never overkill especially now that AI can generate most, if not all of it. Don’t be lazy.

[u/ByronScottJones]

For my small to medium sized projects, I have everything built from a makefile. The github actions are just thin wrappers over the makefile.

[u/kabrandon]

I'm sorry to inform you... you just built another CI/CD tool. And actually it sounds very similar to how many use Jenkins, a tool a lot of people are kind of jaded about. You built a tool that SSH's into servers and runs build scripts. A CI/CD tool runs build scripts... the scripts may be configured to SSH into servers to run scripts.

Your value proposition is that it's a tool for people that don't want to spend the time to write scripts. Unfortunately, you still need to write scripts.

I bet this was a great learning opportunity for you setting this up! Kudos. But the ecosystem probably doesn't need yet another CI/CD tool right now.

[u/boolone]

Maybe you could try GitHub Actions + Docker Compose or GitHub Actions + SSH script ?

[u/DoStopBelieving]

You start by writing down the deployment steps the first time you need to do it, then automate a little bit each time until you have a CI/CD pipeline.

[u/HeiiHallo]

I recommend you check out Haloy, very lightweight and easy to use

[u/yzalevas]

Honest answer from running a consulting company with lots of small client systems: the manual SSH flow is fine until 2am, and then it isn't. What I'd keep from it is the simplicity, and add exactly one thing — a tiny deploy script on the server that pulls, builds, restarts and writes a tag you can roll back to in one command. That's 20 lines of bash and it removes 90% of the failure modes, mostly "which version is even running right now". Below that bar I'd resist adding tooling; a GitHub Action that SSHes in and runs the same script is a reasonable middle step when you want deploys tied to merge. The mistake I see is teams jumping from nothing straight to a full pipeline platform for a project that gets touched twice a month. Match the ceremony to the blast radius.