This is a bit off-topic: a post to share images (screenshots) of your beautiful (or not so much) workflows. Just for the purpose of aesthetics and fun, as there is the n8n.io/workflows to really share the workflows that are useful to share.
I’ll start with this workflow that I did to test a few things in my journey of load tests and memory investigations.
This is cool stuff @AllanDaemon. I don’t have workflows with tons of nodes but I do have some that are a life saver and look … cute. Here they are 
This is a workflow that me and @Ben built to use n8n for releasing new versions to n8n.cloud (inception, right?)
This is a workflow that me and @jan built with help from the design maestro @maxT to create the release graphics that you might have seen on our social media channels.
This is a chatbot of sorts that I built cause why not? Helps us find brand assets from Mattermost quickly 
I nominate @mcnaveen to share screenshots of some of his workflows. I got a sneak peek a few weeks back and it was mind blowing
Wow, this is my favorite thread now. Who do you nominate to share their workflows @mcnaveen?
I nominate multiple persons to share their workflow screenshot or number of workflows screenshot @mskian @harish @RicardoE105 & @jan Come on, We are excited 
Sure. Still not 100% done but is the result of hackmation where we tried to automate the release of n8n with n8n. The git-Node is also still wip and not released yet.
I used the workflows the first time this morning when I released [email protected] but sadly had still some issues with the npm package build that I still have to debug.
This is 
This is awesome bro
This remembers me this flow:
Check if there is a new release in Github and we get commit messages
We publish this stuff to the spanish N8N community channel
Finally, we execute another task that we use to update multiple docker n8n instances in Portainer 
That’s really cool! But you probably have to be careful if the new version contains breaking changes.
We could probably start to publish a simple JSON version of the breaking changes file which at least contains the full names of the nodes that potentially break. So you could then build a workflow that checks before updating if any active workflow contains such a node and then not upgrade in this case
Thanks Jan. Yes, this is risky, I know (only applied to dev environments to test new nodes).
That kind of notified stuff you mean would be helpful to know if deploy could be really done or not.
Not sure if you apply that, but some automated mock tests for credentials, data and results could be nice too to detect if there is any problem.
Yes, workflow tests are wip. Here is the repository with the first workflows:
Why in the earth, I don’t have that Git Node? 
