My earlier response didn’t do a great job addressing the core issue. To improve, I’ve introduced a new tier: "Starting at $7 / Public Docker Image / Month." This provides more clarity for smaller setups while still allowing flexibility for larger use cases through tailored plans.

Right now, I’m keeping a queue to ensure every customer gets a consistent and high-quality experience as we grow. Thanks again for your feedback.

Thanks for the feedback—it’s a valid point, and I’ve been giving a lot of thought to how teams define and approach 'fixes.' In some cases, a fix might mean something as significant as transitioning away from a public parent Docker image to a 0-CVE solution.

That said, this is part of a broader phase-two conversation. Right now, I’m focused on building the foundational layer: keeping things transparent, pulling and sharing public data, and addressing the larger challenges around public Docker image management.

Expanding into customer-specific features is definitely on the roadmap, but we’re taking it step by step. I’d love to hear about the challenges you’ve faced managing fixes and dependencies—what would make the biggest difference for your team?

Fair point, and I appreciate the feedback. Right now, scaling is definitely doable, but I’m still handling some manual tasks daily as I continue refining the process. I can absolutely deliver on the promise, 'Set up before you can brew a cup of coffee. Receive your first pull request before tomorrow's stand-up,' but it does mean working closely with each customer at this stage.

I’m working on automating more of the setup process to streamline scaling further while still keeping that fast turnaround time. In the meantime, I’m handling things on a per-customer basis to ensure everything runs smoothly. Let me know if you think there’s anything else I should focus on to improve the experience!

I’m Kyle, the founder of signal.fyi, a tool designed to simplify parent Docker image version management by decoupling it from your existing CI/CD pipeline. After the Log4Shell event while at a fortune 100 company, it was clear there needed to be a better way of keeping parent image versions up to date while also introducing a way to audit these changes over time.

Key Features: - Automated Image Syncing: Automatically checks and updates parent Docker images independently of your CI/CD pipeline (1/day|max:3 Dockerfiles/repository). --Capped at 5 repositories (for now) - Improved Efficiency: After installing the Github Marketplace App, each version change is introduced via pull request against your default branch. - SBOM context enrichment: The parent Docker image version (digest;fat manifest) will be available to add in metadata of the SBOM you generate.

How It Works: 1. Daily Scans: signal.fyi performs a daily scan to ensure your images are up to date in up to 3 multistage/multi-file Dockerfiles. 2. Notifications: A pull request is opened against your default branch if there is a change from your default branch and/or an existing pull request (open) from a previous day does not already exist. 3. Integration: Easily integrates with existing CI/CD pipelines leveraging pull requests for manual or automated releases.

How we handle data: - We treat Github as our database (as much as possible, but we do store some info about you for retrieval purposes). Considering the data we consume from access is out of date pretty much immediately, it makes more sense for use to just query daily when we are working to keep your version (digest;fat manifest) up to date.

I’d love to hear your feedback and answer any questions you might have!

Thanks, Kyle