Expiration dates
Give a contractor, teammate, or temporary workflow a key that naturally stops working after the date you choose.
HearthGate 1.1 archive
Per-key control, finally.
HearthGate 1.1 introduced Per-Key Limits: expiration dates, time windows, session caps, lifetime-use caps, and duration limits attached to each authorized SSH key individually. The goal was simple: hand out keys that defend themselves.
Time windows
Limit a key to business hours, an on-call rotation, or a timezone-aware maintenance window.
Concurrent session caps
Cap how many live sessions a key can hold, then reject the next attempt or replace the oldest session.
Session duration caps
Close sessions that run too long, so forgotten tunnels do not stay open in the background.
Per-Key Limits
Keys that stop being broader than the job.
The 1.1 release shifted HearthGate from key creation to key lifecycle control. A key could become temporary, scheduled, capped, or self-limiting instead of staying valid until someone remembered to revoke it.
Self-limiting keys
Lifetime use caps
Let a key work a fixed number of times, then auto-quarantine it until you deliberately reset the counter.
Live visibility
Active Sessions panel
See live SSH sessions grouped by authorized key, then disconnect a single session when something looks wrong.
Cleaner stale sessions
Tighter idle timeout
A shorter default keepalive window helps stale laptop, tablet, and sleeping-client sessions disappear faster.
Use cases
Why 1.1 mattered
Per-Key Limits made temporary access feel intentional instead of fragile.
Use case
A 30-day contractor key
Set the expiration when you onboard the contractor. You no longer have to rely on a calendar reminder to revoke it later.
Use case
A business-hours support key
Limit the key to the hours when the work is supposed to happen, then keep the rest of the week outside the allowed window.
Use case
A stale session from another device
Use the Active Sessions panel to see which key is holding a session open, then disconnect the specific session if it looks wrong.
Foundation release
The access model became more granular.
HearthGate 1.1 is the release that made key-level policy a first-class part of the product. Later releases strengthened enforcement and added more network-defense layers on top.
Release notes at a glance
- Expiration dates for short-lived access.
- Day and hour windows for scheduled access.
- Concurrent session caps for keys used across multiple devices.
- Lifetime-use and session-duration caps for keys that should naturally stop.
HearthGate 1.1