Recent Ghostable updates make secret operations safer by default, improve resilience during outages, and standardize release integrity evidence.
We shipped a set of product updates focused on one practical outcome: make secret operations safer by default, easier to monitor, and easier to verify in real team workflows.
These updates span CLI, Desktop, and Dashboard behavior, and reduce day-to-day risk without changing Ghostable's zero-knowledge security model.
Latest versions
- Ghostable CLI: v2.5.2 (NPM)
- Ghostable Desktop: v1.1.3 (Download macOS client)
Push and sync safety is stricter by default
❌ Strict conflict mode blocked this push due to version drift.
- LOCAL_ACCESS_SECRET: local v19 vs server v21
- LOCAL_ACCESS_SECRET_02: local v1 vs server v2
Run `ghostable env state refresh` to update versions, or use --force-overwrite.
Conflict handling on push and sync flows now defaults to strict behavior, which reduces accidental overwrites when multiple team members or systems are changing environment state in parallel.
The CLI now supports explicit conflict controls with --conflict-mode warn|strict and --force-overwrite when an intentional overwrite is actually what you want. Local version baselines are also maintained more consistently through environment state refresh and automatic refresh on pull.
Conflict responses are now deterministic: HTTP 409 with a structured conflicts[] payload. That gives both human users and automation a reliable contract for handling stale-state writes.
Audit webhooks are now observable operations
Organizations can now configure audit webhooks with signed delivery. Delivery behavior includes retries and dead-letter handling, and we added metrics plus health visibility for outcomes so teams can distinguish transient delivery issues from persistent integration failures.
This closes a common monitoring gap: audit events are only useful if security teams can trust they are actually arriving and can quickly detect when they are not. The implementation details and templates live in the SIEM and audit webhook docs.
Deploy fallback is controlled, encrypted, and fail-closed
The CLI now supports encrypted deploy bundle caching with controlled stale fallback via --allow-stale-cache, bounded by TTL and integrity checks. This improves deployment resilience during temporary service disruptions without introducing silent security regressions.
Invalid, tampered, or expired cache artifacts fail closed, and fallback does not bypass authentication failures. In other words, this improves continuity under outages, not trust assumptions. See the deployment behavior details in Deployments.
Desktop conflict handling is more explicit
Desktop now decodes structured conflict payloads and gives direct guidance in stale-version cases: reload for a fresh baseline or intentionally overwrite when appropriate. The goal is clarity under pressure, especially when multiple actors are touching the same environment.
Release integrity evidence is now standardized
Release integrity assets are now produced and published as part of the release process: checksums, SBOMs, and provenance where the platform supports it. Verification guidance and security controls documentation were also updated.
For private repositories, workflows were adjusted to handle attestation-plan limitations while still publishing practical integrity evidence teams can validate. If your organization validates build origin and artifact lineage, this aligns with the direction of frameworks like SLSA provenance and gives you concrete artifacts to check.
What this changes for teams
- Fewer accidental secret overwrites during concurrent changes
- Clearer stale-state prompts and conflict resolution flows
- Better deploy reliability during temporary outages, without weakening controls
- More transparent audit trails and delivery visibility for security teams
- Stronger trust signals for teams that verify what they install
What this does not change
These updates do not relax authentication boundaries, do not allow Ghostable to read secret values, and do not turn fallback behavior into an override of security controls. They are operational hardening updates to default behavior and visibility, not a shift in security model.
Upgrade and verify
If you want to adopt these changes now, review supply-chain verification, and share the updated controls view with security stakeholders via the security controls matrix. You can also share Ghostable's trust overview from ghostable.dev/trust.
Desktop
Open Ghostable, then go to Ghostable -> Check for Updates and choose Install and Relaunch.
CLI
Update the CLI globally with:
npm install -g @ghostable/cli@latest
Top comments (0)