pacmansyyu

Although from first look, I can tell you that there's a lot of text on the site and it's a bit too cramped. From my perspective, tools like these should get out of the way and the UX should be self-explanatory for an image "conversion" tool. Basically, just a box to select, drag/drop images, a few user inputs such as the output quality and format. That's about it. A single line at the top explaining what the tool does (and that it is local) should be good enough.

Also, the title says "PNG to JPG converter," but the rest of the site claims it can convert to quite a lot more than just those format. You can possibly change that to, as an example, something like: "ImageConverter - Convert images between formats, locally". And you can get rid of multiple pages, turning it into a single-page with all the possible output options.

The idea came to me when we were trying to find ways to manage Terraform secrets , CI vars were a no-go because people sometimes wish to deploy locally for testing stuff, and tools like Vault have honestly been a pain to manage, well, for us at least. So I have been building this tool where the variables are encrypted with `age`, have RBACs around it, and an entire development workflow (run ad-hoc commands, export, templating, etc) that can easily be integrated into any CI/CD alongside local development. We're using this and storing the encrypted secrets in Git now, so everything is version-controlled and can be found in a single place.

Do give it a try. I am open to any questions or suggestions! Interested to know what people think of this. Thanks!

A few examples of what it can currently do:

- Automated data backup: Listens for Nomad job events and spawns auxiliary jobs to back up data from services like PostgreSQL or Redis to your storage backend based on job meta tags. The provider for this is not limited to backups, as it allows users to define their custom job and ACL templates, and expected tags. So it can potentially run anything based on the job registration and de-registration events.

- Cross-namespace service discovery: Provides a lightweight DNS server that acts as a single source of truth for services across all namespaces, solving Nomad's limitation of namespace-bound services. Works as a drop-in resolver for HAProxy, Nginx, etc.

- Event-driven task execution: Allows defining custom actions triggered by specific Nomad events; perfect for file transfers, notifications, or kicking off dependent processes without manual intervention. This provider takes in a user-defined shell script and executes it as a nomad job based on any nomad event trigger the user defines in the configuration.

Damon uses a provider-based architecture, making it extensible for different use cases. You can define your own providers with custom tags, job templates, and event triggers. There's also go-plugin support (though not recommended for production) for runtime extension.

I built this to eliminate the mundane operational tasks our team kept putting off. It's already saving us significant time and reducing gruntwork in our clusters.

Check out the repository[1] if you're interested in automating your Nomad operations. I'd love to hear your thoughts or answer any questions about implementation or potential use cases!

Surprisingly, Umami has been handling our traffic volume without breaking a sweat on much smaller instances. I suspect PostgreSQL's superior handling of concurrent writes plays a big role here compared to MySQL/MariaDB. Except for the team/user management, everything feels much nicer on Umami.

Shameless plug: As part of the migration, I also took the opportunity to learn some Rust by writing a small utility that uses the Umami API to generate daily/weekly analytics reports and sends them via email[1]. Pretty happy with how it turned out, though I'm still learning Rust so any feedback or suggestions for improvement are welcome!