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.

As a sidenote, I've been using Mazanoke for this: https://github.com/civilblur/mazanoke. It's not my project, just something I happened to stumble upon a while ago, but it's similar to your project and works exactly like you would want it to.

From my test, the rest of it works great. Good luck!

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!

[1]: https://kiln.sh

kiln also lets you have different access controls per environment file (devs get staging, only ops get production) without separate .sops.yaml configs, automatically discovers keys from SSH agent/~/.kiln/, and has built-in template rendering and export formats for different tools. You could definitely build similar workflows with SOPS + scripts, or any other tool, but kiln packages these common patterns into a single tool with better UX for teams.

Think of kiln as "opinionated SOPS", focused specifically on environment variables rather than general file encryption.

You know the drill - someone needs the staging database URL, so it gets shared over chat. Production API keys end up in plaintext files. Or you set up some complex secret management system that becomes a single point of failure during critical deployments.

At Zerodha, we're a stock broker with strict regulatory requirements. Our infrastructure needs to be auditable, and our data must stay with us for instant recovery. But the deeper issue was that every solution we tried made deployments dependent on external services.

We tried GitLab CI's built-in secrets, but they're stored unencrypted and only repository maintainers can access them. HashiCorp Vault was too complex to manage with painful ACL setup, plus it's now crippled by their BSL license change. AWS Secrets Manager would create the vendor lock-in we wanted to avoid.

The breaking point came when we wanted to manage secrets through Terraform for idempotency and better infrastructure-as-code practices. But Terraform has no built-in way to encrypt secrets without relying on external providers. We could either store secrets in plaintext in our Terraform configs or add yet another external dependency to our deployment pipeline.

That's when I had the idea: what if we could inject encrypted environment variables directly into Terraform, so anyone with the right key could deploy without hunting down secrets from different systems? As I iterated through this idea, I realized the same pattern would work for any application - from personal projects to team deployments.

So I built kiln. It encrypts environment variables using age encryption into files that live alongside your code. No servers, no network calls, no external dependencies. Each team member gets their own key, and you control access per environment.

Here's how it works:

  # Generate a new age key, or use your existing SSH keys
  kiln init key
  
  # Initialize with your team's public keys
  kiln init config --recipients "alice=$(curl https://gitlab.company/alice.keys)" --recipients "me=$(cat ~/.ssh/id_ed25519.pub)"
  
  # Set secrets (prompts securely, never shows in terminal)
  kiln set DATABASE_URL
  kiln set API_KEY
  
  # Run your app with decrypted environment
  kiln run npm start
  

  # These encrypted files are safe to commit
  git add .kiln.env kiln.toml

Why not raw age encryption? Age is perfect for the crypto layer, but terrible for day-to-day team workflows. Try managing 20 team members across 5 environments with raw age commands - you'll go insane. kiln handles the orchestration.

As for technical details, kiln:

- Uses age encryption (modern, audited, simple)

- Works with existing SSH keys or generates new age keys

- Role-based access via TOML configuration

- Single, cross-platform Go binary

- Zero network dependencies - everything works offline

- MIT licensed

The game-changer: secrets travel with code. No more "can someone send me the staging secrets?" in chat. No more broken deploys because the secret service is down. No more hoping your vendor doesn't change their pricing or licensing.

Try it out - I'm confident it'll help improve your team's deployment workflows. Feel free to ask me any questions!

GitHub: https://github.com/thunderbottom/kiln

Docs: https://kiln.sh

Or install now: go install github.com/thunderbottom/kiln@latest

Comments URL: https://news.ycombinator.com/item?id=44594367

Points: 12

# Comments: 2

At first, I did consider using them instead of building my own tool on top of age. But our requirements were far beyond just encrypting and decrypting files in a single environment.

What kiln adds here is the role-based access control, so you can define multiple files, and users/groups who should be able to access them. It also adds to the developer workflow where you can directly run commands through kiln with the variables injected in the command's shell environment. You can also render templates for all the kiln-encrypted files you have access to.

You can say it's a wrapper over age, but adds functionality that allows seamless sharing of developer workflows, and environments, all from a single place. It's git-friendly, and primarily aims for your secrets to travel along with the code so all deployments can be done offline (as an alternative to something like Infiscal, or Vault). I've tried to make it as simple as possible to adopt for anyone in the team.

The only other best way for me to put it is that you should try it out, and I'm sure it'll be helpful in a lot of ways. If you have any more questions, I'm happy to answer them!

Every team handles secrets badly. Secrets and passwords get shared in Slack, `.env` files sit in plaintext, or you depend on external secret management services that can fail during critical deployments, or even depend on other people to deploy things for you!

I believe your environment secrets should neither depend on external services or people, nor be shared in plaintext.

kiln is a command-line tool for managing encrypted environment variables. It lets you encrypt secrets into files that can be safely committed to version control, with role-based access control so team members can only decrypt the environments they're authorized for.

What kiln does:

- Encrypts environment variables using age encryption with SSH and age keys

- Role-based access control - each file can have different access levels

- Commit encrypted files safely to git with clean diffs

- Run applications or render config templates with automatic secret injection

- Works completely offline - no external dependencies

Instead of depending on external services, your secrets travel with your code and work everywhere. You define team access in a config file, encrypt your secrets, and everything just works.

Built as a single Go binary that uses your existing SSH keys or generates new age keys.

Try it out and let me know what breaks or what's missing. I'd love to hear how this fits into your team's workflows and what could make it better.

GitHub: https://github.com/thunderbottom/kiln

Docs: https://kiln.sh

Comments URL: https://news.ycombinator.com/item?id=44559131

Points: 4

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=44098605

Points: 148

# Comments: 151

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!

[1]: https://github.com/Thunderbottom/damon

For plausible I believe that since it runs on Postgres, scaling should not be a problem as long as you scale the resources with it.

You’re right about MySQL performing alright for 10-20m rows, but from our perspective those numbers are not that big for a company this size.

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!

[1]: https://github.com/Thunderbottom/umami-alerts

In the meanwhile, if you would like to submit the project, you could use the following URL which redirects to the `raw.githubusercontent.com` page: https://github.com/nativephp/laravel/raw/main/.well-known/fu...

I hope this helps!

[1]: https://github.com/nativephp/laravel/blob/main/.well-known/f... [2]: https://raw.githubusercontent.com/nativephp/laravel/refs/hea...

> Instead of structuring this as a fund, why not a non-profit?

Thank you, this is an interesting suggestion. While a non-profit structure could potentially increase donations, implementing this globally would be extremely complex.

Particularly because tax laws vary by country, which would require us to be registered as a non-profit in most, if not all countries, and comply with their jurisdiction. The administrative overhead and legal complexities of managing a truly international non-profit outweighs the benefits for our current scale. We appreciate the idea and will keep it in mind as we grow, but for now, we're focusing on efficiently directing funds to FOSS projects through our current model.

Comments URL: https://news.ycombinator.com/item?id=25195827

Points: 2

# Comments: 0

> you can save some bandwidth in exchange for recording quality by using high compression of Speex algo

how about using opus[0], the comparison chart[1] shows that opus is supposedly significantly better even at a lower bitrate.

[0]: https://www.opus-codec.org/

[1]: https://www.opus-codec.org/comparison/

Comments URL: https://news.ycombinator.com/item?id=19274261

Points: 1

# Comments: 0