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.

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.