Changelog

Foglift ships changes continuously, with user-facing release notes batched into versioned entries on this page. Most weeks include at least one new feature, several improvements, and bug fixes. Major releases (v1.0, v2.0) mark significant capability expansions. Subscribe via RSS at /rss.xml to be notified when new entries land, or follow the changelog directly. There is no separate beta channel. Every customer on every plan receives the same product on the same day.

Once published, changelog entries are immutable. Dates, version numbers, and item descriptions are not edited after release. If a feature mentioned in an old entry is later renamed, removed, or reworked, the change is documented as a new entry rather than a retroactive edit. This keeps the changelog usable as a historical reference for integrators, security reviewers, and procurement teams who need to verify what shipped when.

New marks a capability that did not exist before, such as a new dashboard, page type, API endpoint, integration, or scoring dimension. Improved covers enhancements to existing capabilities, including UX polish, performance gains, expanded coverage, or refined heuristics. Fixed denotes bug fixes that restore intended behavior. Removed denotes a deprecation or sunset. Every changelog entry uses one of these four labels per item so readers can scan for the kind of change they care about.

The public roadmap lives at /roadmap and covers what is shipping next across the four product surfaces (audit, monitoring, crawlers, recommendations). The roadmap is directional, not a commitment of dates. The changelog on this page is the canonical record of what has actually shipped. If you want input into roadmap priority, write to hello@foglift.io with your use case and we will route it to the relevant build cycle.

Yes. Breaking changes to public API endpoints, CLI commands, and the MCP server are called out in changelog entries with the Fixed or Improved label and a migration note. The npm packages @foglift/foglift-scan, @foglift/foglift-mcp, and @foglift/tracker follow semantic versioning. Patch and minor releases are backward compatible; major releases include a migration guide. See /docs for the current API surface and /integrations/cli for CLI command reference.

If you have an open feature request with the team, the build cycle that ships it will reference the request in the corresponding changelog entry. The most reliable way to track is to add the changelog RSS feed at /rss.xml to your reader, then search the entries page on push. Customers on Pro tier and above can also opt into changelog email digests in dashboard settings (currently rolling out). Contact hello@foglift.io if you want early access.

Foglift treats high-quality educational content (blog guides, comparison pages, glossary, listicles) as a first-class product surface, because that content is what AI engines crawl and cite when surfacing Foglift to potential users. Content launches that materially expand topical authority (a new persona-targeted listicle, a new vertical guide, a glossary expansion) appear in the changelog the same way a new dashboard would. This is the dogfooding loop in action: we publish what we recommend our customers publish.

For security-relevant changes (SSRF protection, RLS policy fixes, auth flow updates, third-party script audits), the changelog records the user-visible summary and ship date. The deeper security history lives in the GitHub commit log and the audit trail in the codebase. For compliance documentation, vendor security questionnaires, or SOC 2 evidence requests, contact hello@foglift.io. The changelog is the public record; the security@foglift.io channel is the authoritative source for compliance artifacts.