smjburton

> In March 2026, I migrated to self-hosted object storage powered by Versity S3 Gateway.

Thanks for sharing this, I wasn't even aware of Versity S3 from my searches and discussions here. I recently migrated my projects from MinIO to Garage, but this seems like another viable option to consider.

This is a great resource OP. Hopefully with more guides like this available, it will make it easier for people who want to explore Podman and increase adoption.

Very cool, I'll take a look.

You're very welcome! Good luck.

> ... is it primarily by inputting code snippets or abstract context into something like a Claude or ChatGPT?

I usually provide the initial context by describing the app that I'm working on (language, framework, etc) as well as the feature I want to build, and then add the files (either snippets or upload) that are relevant to build the feature (any includes or other files it will be integrating with).

This keeps the chat context focused, and the LLM still has access to the code it needs to build out the feature without having access to the full code base. If it needs more context (sometimes I'll ask the LLM if they want access to other files), I'll provide additional code until it feels like it has enough to work with to provide a solution.

It's a little tedious, but once I have the context set up, it works well to provide solutions that are (mostly) bug free and integrate well with the rest of my code.

I primarily work with Perplexity Pro so that I have access to and can switch between all pro level models (Claude, ChatGPT, Grok, etc) plus Google search results for the most up-to-date information.

> Since our landing page is isolated from core product code, the risk was minimal. That said, I was constantly sanity-checking what Claude was changing. If I ever “vibed” too hard and lost focus, Claude would sometimes change the wrong files.

> Still, I wouldn’t trust Claude, or any AI agent, to touch production code without close human oversight.

My experience has been similar, and it's why I prefer to keep LLMs separate from my code base. It may take longer than providing direct access, but I find it leads to less hidden/obscure bugs that can take hours (and result in a lot of frustration) to fix.

This is great, thank you for sharing. I need something like this for my current project I'm working on... Much easier than trying to build a color palette manually.

Agreed OP. I could see ProductHunt being a place for product-oriented people and founders to form a community and collaborate (constructive feedback, partnerships, etc). Sadly, most of the activity there lately seems to be people quickly creating accounts, launching their vibe-coded app, and then moving on. I've stopped visiting regularly until the maintainers make improvements to foster more of a community and bring people back to the site.

I'm surprised, but you're right... Thanks for sharing this site, it'll be interesting to dig into the data.

I generally agree with the sentiment of the article, but the OP should also be looking at product launch websites like ProductHunt, where there are tens to hundreds of vibe coded SaaS apps listed daily.

From my experience, it's much easier to get an LLM to generate code for a React/Tailwind CSS web app than a mobile app, and that's why we're seeing so many of these apps showing up in the SaaS space.

I've been running trixie for a few weeks now and it's been solid, great release so far.

One of the features I'm most excited about is access to Podman 5.4.2, and the ability to use Podman Quadlets. It'll be nice to start transitioning my systemd service units over to the new format for my containers.

Good breakdown of the costs involved. Even if they're running at a loss, OpenAI and Anthropic receive considerable value from the free training data users are providing through their conversations. Looking at it another way, these companies are paying for the training data to make their models better for future profitability.

Interesting article OP. There was a similar post on Hacker News recently about using this approach on a Postgres database:

- Making Postgres slower (https://news.ycombinator.com/item?id=44704736)

Taking this approach seems to be effective at surfacing issues that otherwise wouldn't show up in regular testing. I could see this being useful if it was standardized to help identify issues before they hit production.

This is an interesting find OP and could help people transition from Docker to Podman (especially if they're used to deploying with Docker-Compose).

I think the better long-term approach though is to use systemd user units for deployment, or the more modern approach of using Podman Quadlets. There's a bit of a learning curve, but these approaches are more native to the Podman platform, and learning how systemd services work is a great skill to have.

> The more data you give any of the AI services, the more that information can potentially be used against you.

It may seem obvious, but Sam Altman also recently emphasized that the information you share with ChatGPT is not confidential, and could potentially be used against you in court.

[1] https://www.pcmag.com/news/altman-your-chatgpt-conversations...

[2] https://techcrunch.com/2025/07/25/sam-altman-warns-theres-no...

Thanks for sharing this. It looks like you can also use "systemd-analyze" with the "--user" flag to inspect systemd user units as well ("systemd-analyze --user security"). I've started using systemd more now that I've transitioned my containers to Podman, and this will be a helpful utility to improve the security of my systemd unit/container services.

This is really exciting. I've used the Arch Wiki countless times for setting up or configuring something in Debian but wanting a resource more native to the platform. I hope they're able to produce a comparable wiki for Debian-based OSes.

@levelsio was posting about this last week: https://x.com/levelsio/status/1953022273595506910. Haven't tested it out yet, but it seems like a cool way to continue hacking away at a project while on the go.

Self-hosted Forgejo with Forgejo Actions for CI/CD. Forgejo Actions uses a syntax similar to GitHub Actions, so it's easy to transition. For my projects, I haven't had any issues. I'd suggest setting up an instance and testing it out to see if works with your projects/workflow as a replacement for GitHub/GitHub Actions.

Why would you not want people trusting their data with SaaS apps? Smaller developers building software benefits users assuming their data is protected with basic security implemented.

It's not new, but I believe vibe coding is going to make it more common. Both this app and Tea's data breaches could have been avoided with basic web dev security.

It's concerning that these type of leaks keep happening. Outside of the damage from leaking personal information, they also lower public confidence in trying out new apps. Vibe coding is making it more difficult for app makers in general when users can't trust that their personal information is protected.

Another benefit of using text other than "click here" is that it's helpful for web crawlers too. Google, Bing, and other crawlers use link context (e.g. "lawn care in new jersey" vs "click here") to establish authority/relevance for the site being linked to. The closer the context of the link, the more authority a website (generally) gets for that topic.

It's unfortunate to see this go away, but understandable given the costs involved. Another option is to run Caddy as a web server, which provides automatic cert renewal (https://caddyserver.com/docs/automatic-https). If notifications are still important, they also provide an event subscription system (https://github.com/caddyserver/certmagic#events) so you can subscribe to cert-related events, run custom code, trigger event handlers, etc.

Great article OP. This is exactly what made the "old web" so great: there were no defined standards so people were compelled to experiment. It was a little more chaotic, but it felt more rewarding when you came across a cool website with a unique design. The modern web on the other hand is very structured and formulaic, served mostly through the same templates and frameworks. Instead of being a place to explore, it's largely become a place to consume content in a predictable fashion.

If you find out, please let me know... :)

> Today it’s the fashion to make web services in a very “lightweight” way, to offer minimally viable web products free, and to iterate rapidly as experience is gained with initial web users.

> I really envy people doing software with the web. One could do much better these days. But we didn’t have it, and so we were forced to do many things that wouldn’t be sensible today.

It's true there's a lot less cost and overhead to build and ship software today, but this is a double-edged sword: the perceived value of the software is also lower, and so people are less willing to pay and even expect the product to be free. I would argue it's much more difficult to build a software business these days because of this. If you can't sell your product, it's impossible to build a sustainable business.

Very cool OP listening to the original samples compared against the different harmonizers and vocoders.

The Sennheiser VSM201 sounds so clean, I really like the analogue sound. The TC Helicon Talkbox Synth also sounds nice.

For the harmonizers, the Digitech Studio Vocalist EX sounds the best to me, but I also like the Korg ih Interactive Vocal Harmony for its spacey vocal effects.

> When an article is requested multiple times, we memorize – or cache – its content in the datacenter closest to the user. If an article hasn’t been requested in a while, its content needs to be served from the core data center.

Maybe a similar system needs to be set up so that bot requests need to present their latest cache or hash ID of the requested content before a full request can be granted. This way, if the local cache is recent, it doesn't burden the server with requests for content they've already seen, and they can otherwise serve their users information based on the version they have stored locally.

This is interesting, thanks for sharing.