Credentials and keys delivered to the intended recipient, for only as long as required
SecretLink encrypts credentials, keys, text and attachments in the sender’s browser. The server stores only encrypted content and does not receive the key required to open it; when the first configured limit is reached, either view count or expiry, the content is deleted.
- Authenticated AES-256-GCM encryption in the browser
- Explicit reveal, resistant to automated link scanning
- Self-hosted deployment and organisation-defined policies
Deletion rules defined before delivery
Expiry and view count are configured separately. SecretLink displays the complete rule before creation and deletes the encrypted content as soon as either limit is reached.
Recipient-initiated reveal
Visiting the link does not consume a view. The count advances only after an explicit recipient action, preventing previews and email-security systems from deleting the secret.
Status and revocation
The sender can review views, remaining time and secret status; expiry can be extended while the content still exists, or the secret can be deleted immediately.
Deletion at expiry
A dedicated process deletes expired encrypted content without waiting for another access. Its status, backlog and any interruption are exposed through operational checks.
Sender receipt
The receipt records the identifier, expiry, permitted views and applied safeguards, together with controls for copying the link, generating a QR code and revoking the secret.
The decryption key never passes through the service
The key is generated in the browser and placed in the URL fragment, which is not transmitted to the server. The recipient uses the key to decrypt the content on their device after verifying its integrity.
Versioned encrypted format
Text and attachments are placed in an authenticated AES-256-GCM envelope. Format versioning identifies precisely which protocol applies to each item.
Streaming file encryption
Files are encrypted and transferred in chunks, with progress, cancellation and controlled resumption. Storage can use local disk or S3-compatible services.
Deployment configurations
SQLite and local disk support a single node; PostgreSQL, S3-compatible storage and stateless application servers support distributed deployments. Production Compose and a Helm chart are available.
Protection levels based on content sensitivity
The expiring link is the basic delivery method; more sensitive content can also be protected through channel, identity and access-attempt controls.
Separate key transmission
The link and opening code can be sent over separate channels. Intercepting only one of the two elements does not allow the content to be opened.
Recipient verification
Reveal can require a password, email-address verification or corporate identity through OAuth 2.0 and OpenID Connect, including restriction to defined users or domains.
Password protection
Password derivation takes place in the browser with Argon2id. Minimum strength, attempt limiting and deletion after a configured number of failures are governed by organisational policies.
Separate delivery for each recipient
The same content can be associated with separate links, each with its own recipient, key and lifecycle. Status remains independently reviewable for each delivery.
Scheduled activation
Content can be made available only from a defined date and time. Before activation, the link does not permit reveal.
Recipient interface
The reveal page presents the sender, applied rule and required action without promotional content or third-party scripts. After reveal, fields remain masked and can be copied separately.
Credential collection without plaintext replies
SecretLink also protects the reverse path: a request link lets clients, technicians and suppliers submit credentials without plaintext email, chat or tickets and without creating an account.
Encryption before submission
The response is encrypted in the submitter’s browser. Only the request owner can open it.
Templates and reusable requests
Recurring fields, response quota and expiry can be saved as templates. A request can collect multiple independent responses within defined limits.
Requester identity
The response page presents the requesting organisation through an identity signed by the service. An agreed phrase can be checked over a second channel before submission.
Central policies and operation traceability
Administration defines the limits within which users operate and separates encrypted-content retention from the metadata required for oversight and operations.
Policies and defaults
Duration, views, passwords, attachments, size, permitted domains and networks are defined for the organisation. Preconfigured profiles apply consistent combinations to different flows.
Roles and audit log
Owners, administrators, members and reviewers have distinct scopes. The audit log records events and configuration changes without requiring access to content or keys.
Identity and automation
Passkeys, external identity providers and corporate OAuth 2.0/OpenID Connect systems can coexist. A versioned API, scoped tokens, command-line tools and a Terraform provider integrate operational workflows.
Operational controls
Production configuration is checked at startup. Health checks, metrics, traces and diagnostics cover the database, storage, email, identity and deletion process.
Adoption contexts
SecretLink covers the temporary handover of a secret; the password manager continues to retain long-lived credentials. The two functions remain distinct and complementary.
Service and support
Delivery and collection of temporary credentials for clients and users without retaining them in tickets or messages.
Systems and infrastructure
Handover of production keys and access between technicians, suppliers and authorised staff, with defined expiry and recipients.
Staff onboarding
Initial credentials, documents and personal data delivered to new starters through a focused, expiring flow.
Suppliers and advisers
Time-limited access for external collaborators, restricted to the duration of the engagement and revocable by the sender.
Assessment of the first delivery workflow
DEC can review secret types, recipients, duration, verification requirements, organisational policies, identity and infrastructure to define a verifiable SecretLink scope.