The Problem with External Parties

Internal credential sharing has good solutions. Your team probably uses a password manager — 1Password, Bitwarden, Keeper — and sharing within the org is straightforward.

Contractors and vendors are a different problem. They’re not in your directory. They don’t have access to your vault. They’re working with you for six weeks or six months, and during that time they need database credentials, API keys, staging environment logins, service account passwords.

The typical path is the fastest one available: a Slack DM, an email, a Teams message, a text. It takes ten seconds and works immediately.

It also means that credential is now sitting in a message history that will outlive the engagement by years. When the contractor is gone, the credential isn’t.

What Typically Goes Wrong

The issue isn’t that people are careless. It’s that none of these tools were designed for credential sharing, and they all default to persistence.

How Ephemeral Sharing Works

The concept is straightforward. Instead of sending the credential itself, you send a link. The recipient opens the link, retrieves the credential, and the link self-destructs.

With Password Pusher, the workflow looks like this:

1. Paste the credential and set an expiration — after one view, after 24 hours, or whatever makes sense
2. Optionally add a passphrase (communicated separately — a phone call works)
3. Send the generated link to the contractor through whatever channel you normally use
4. The contractor opens the link, copies the credential, and the link is permanently destroyed
5. You get a full audit trail — who accessed it, when, how many times

The contractor doesn’t need an account. No signup, no login, no app to install. They click a link, get the credential, and the link is gone.

If a link scanner (Microsoft 365 and Google Workspace both do this) opens the link before the contractor does, the retrieval step catches it — the link requires a deliberate click to reveal the payload, so automated scanners don’t consume the view.

The Other Direction: Collecting Credentials from Contractors

This is the part most guides skip. Sharing credentials with contractors is half the problem. The other half is collecting credentials from them.

A contractor sets up a staging server and needs to hand you the admin credentials. A vendor provisions an API key and needs to get it to your team. An MSP rotates a client’s service account password and needs to deliver it securely.

Password Pusher’s Requests feature handles this. You create a request link and send it to the contractor. They open it, paste the credential, and submit. You receive it as a self-destructing push with the same audit trail and automatic expiration.

The contractor still doesn’t need an account. They just fill in a form and submit.

What About Password Managers?

Password managers are the right tool for ongoing, internal credential management. If a contractor needs persistent access to shared credentials over the life of an engagement, adding them as a guest in your vault (1Password, Bitwarden, Keeper) may be the better answer.

Where ephemeral sharing makes more sense:

• One-time handoffs — a credential the contractor needs once during onboarding, not ongoing
• Contractors who won’t create an account — some won’t, especially for a short engagement
• Compliance-sensitive environments — you need a record that the credential was accessed exactly once and then destroyed
• The other direction — most password managers don’t have a mechanism for external parties to submit credentials to you

These approaches aren’t mutually exclusive. Plenty of organizations use a password manager for their team and ephemeral links for external handoffs.

Where This Might Not Be the Right Fit

Ephemeral sharing solves the ad-hoc credential handoff. It doesn’t solve:

• Ongoing access management — if a contractor needs persistent access to a system, provision them a proper account with scoped permissions and an expiration date
• Application-level access — if you can grant access via SSO or OAuth instead of sharing a password, do that
• Credential rotation — if a credential is shared frequently with many parties, the underlying problem is probably that the system needs better access controls, not a better sharing mechanism

Getting Started

Password Pusher is free for basic sharing — no account required. Premium adds file attachments, auto-dispatch email delivery, and custom branding so contractors see your domain and logo instead of pwpush.com.

The open source edition can be self-hosted on your own infrastructure if your security policy requires it. The security-critical code — encryption, data handling, expiry, audit logging — is fully auditable on GitHub.

For API-driven workflows (onboarding automation, CI/CD credential delivery), the JSON API supports everything the web interface does.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

AI agents have a credential problem

Every useful AI agent eventually needs a credential. An API key for a third-party service, a database password for a migration script, an OAuth token for a customer’s system, a license key for a deployment. The agent cannot do its job without the secret, and someone — or something — has to deliver it.

This is not a theoretical concern. A 2026 survey of 919 executives and practitioners found that 88% had confirmed or suspected a security incident involving AI agents. A separate Pulse Research study (107 enterprises, July 2026) found that 69% have credential sharing somewhere in their agent fleet — and those organizations experienced incidents at a 63.5% rate, compared to 40.9% for organizations that give every agent its own scoped identity.

The Cloud Security Alliance published guidance in July 2026 recommending that organizations treat AI agent identities as a separate governance category, with dedicated lifecycle policies for the credentials they carry. Microsoft expanded its Zero Trust framework specifically to address AI agent credential management.

The patterns driving these incidents are familiar: credentials hardcoded in agent configurations, API keys in environment variables that never rotate, secrets pasted into prompts or stored in agent memory. The same patterns that made .env files the leading source of credential leaks in traditional software, now replicated in agent workflows.

Two models for giving agents credentials

The approaches emerging in the market split into two categories.

Persistent vault access. The agent authenticates to a secrets vault at runtime and fetches scoped, time-limited credentials on demand. Bitwarden’s Agent Access SDK, 1Password’s integrations for Claude and Codex, and C1’s Agentic Vault all follow this model. The agent maintains an ongoing relationship with the vault. This is the right approach for production systems that run continuously, access multiple services, and need automated credential rotation.

Ephemeral handoff. The credential is delivered to the agent via a one-time channel — a self-destructing link, a short-lived token, a temporary endpoint — that ceases to exist after the agent consumes it. There is no vault relationship. There is no standing access to revoke. The credential was delivered, consumed, and the delivery mechanism destroyed itself.

These are not competing models. They solve different problems.

When ephemeral handoff is the right choice

Persistent vault access makes sense when an agent runs continuously, accesses many services, and needs credentials that rotate automatically. It is infrastructure.

Ephemeral handoff makes sense when:

• A human is giving a credential to an agent for a specific task. An IT admin passing a database password to a migration agent. A developer sharing an API key with a coding assistant for a single session. A security team provisioning a temporary access token for an audit workflow.

• The credential should not persist in the delivery channel. Pasting an API key into a chat prompt means it lives in chat history indefinitely. Emailing a password means it sits in an inbox. A self-destructing link eliminates the credential from the channel after it has been read.

• You need an audit trail for the handoff itself. When was the credential shared? Was it accessed? By whom? When did it expire? These questions matter for compliance, and they require the delivery mechanism to track its own lifecycle — not just the credential’s.

• The agent workflow is ad-hoc, not continuous. Many agent interactions are one-off: a consultant running a diagnostic, a support engineer accessing a customer environment, a developer testing against a staging API. These do not justify vault integration.

How this works with Password Pusher

Password Pusher’s REST API supports this workflow directly. Create a push with the credential, configure it to expire after one view or a short time window, and hand the URL to the agent.

curl -X POST https://pwpush.com/api/v2/pushes.json \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "push": {
      "payload": "sk-proj-abc123...your-api-key",
      "expire_after_views": 1,
      "expire_after_days": 1,
      "retrieval_step": true,
      "note": "API key for migration agent - task #4821"
    }
  }'

The response includes a URL. The agent (or the agent’s operator) retrieves the credential from that URL. After one view, the push is destroyed. The audit log records when it was created, when it was viewed, and from which IP address.

A few details that matter for agent workflows:

• retrieval_step: true adds a confirmation step before revealing the payload. This prevents email security scanners and URL preview bots from consuming the single view before the agent can.
• note is an encrypted private field. Use it to link the push back to the workflow or ticket that triggered it — useful for audit trails.
• expire_after_views: 1 means exactly one retrieval. Combined with a short expire_after_days, the credential exists in the delivery channel for the minimum possible window.
• The push payload is encrypted at rest with AES-256-GCM. The encryption layer is open source and auditable.

For automated workflows, the same API call can be made from a CI/CD pipeline, a runbook, or an orchestration layer. The pattern is the same: create, deliver, consume, destroy.

Where this might not be the right fit

Ephemeral handoff is not a vault replacement. If your agent needs to access the same credential repeatedly across sessions, rotate credentials automatically, or manage a portfolio of secrets for multiple services, you need a secrets manager. Password Pusher does not store credentials persistently and does not do runtime credential injection.

It is also not a zero-knowledge system. The server encrypts payloads at rest, but the payload is decrypted server-side for retrieval. If your threat model requires that the server operator never sees the plaintext, you need a client-side encryption tool.

What it does well is the handoff itself: get a credential from point A to point B, verify it was received, and ensure it does not linger in the channel afterward.

Availability

The REST API is available on all editions of Password Pusher: the free hosted service at pwpush.com, paid plans with additional features (file attachments, team policies, SSO), and the open source self-hosted edition.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

Why Webhooks

Until now, keeping external systems in sync with Password Pusher meant polling the API or checking the dashboard manually. If you wanted a Slack notification when a credential request got a response, or a log entry when a push was first viewed, you had to build that polling loop yourself and accept the delay.

Webhooks invert that. Instead of your system asking Password Pusher “did anything happen?”, Password Pusher tells your system the moment something does. That opens up a set of workflows that were previously impractical: triggering a follow-up action when a push expires, logging delivery events to a SIEM, alerting a channel when a credential request gets a response, or feeding push activity into an internal dashboard.

How It Works

Webhooks are configured per workspace. Workspace admins can create up to 5 endpoints, each subscribed to the specific events that matter for that integration.

To set one up:

1. Sign in on us.pwpush.com or eu.pwpush.com with an active Pro subscription.
2. Open Workspace → Policy → Webhooks.
3. Choose Add Webhook.
4. Provide a name, your HTTPS endpoint URL, generate a signing secret, and select which events should trigger deliveries.
5. Save and enable.

When a subscribed event occurs, Password Pusher sends an HTTPS POST to your endpoint with a JSON body containing metadata about the event.

Supported Events

You can subscribe to any combination of push and request events:

Only events you subscribe to will generate deliveries. You can change your subscriptions at any time by editing the webhook.

What Your Endpoint Receives

Each delivery is an HTTPS POST with a JSON body and a set of standard headers:

{
  "type": "push.created",
  "occurred_at": "2026-08-07T10:30:00.000000Z",
  "data": {
    "workspace": {
      "id": "acct_oxQdpMWVm",
      "name": "Your Corporation"
    },
    "metadata": {
      "has_files": true
    },
    "push": {
      "url_token": "fjah-38fj2lanvbfke",
      "created_at": "2026-08-07T10:30:00.000000Z",
      "expires_at": "2026-08-08T10:30:00.000000Z"
    }
  }
}

Request events use a request object instead of push, and request.response_received also includes responded_at and metadata.include_requestor.

The payload is metadata only. Secret content — push payloads, passphrases, request responses — is never included in webhook deliveries. If your workflow needs the actual content, retrieve it through the Password Pusher UI or API v2.

Delivery Headers

Every delivery includes these headers:

Your endpoint must use HTTPS, resolve to a public host, and return an HTTP 2xx status for the delivery to be considered successful.

Signature Verification

Deliveries are signed using the Standard Webhooks specification. When you create a webhook, you generate a signing secret (whsec_...) that Password Pusher uses to sign each delivery. Your endpoint verifies the signature against the raw request body using the webhook-id, webhook-timestamp, and webhook-signature headers.

The advantage of Standard Webhooks is that you do not need to write custom crypto. Official verification libraries exist for Python, JavaScript/TypeScript, Ruby, Go, Java, and other languages. Most of them handle timestamp tolerance checks as well, so you get replay protection for free.

Store your signing secret securely. It is encrypted at rest in Password Pusher and shown only once at creation — after that, the UI shows it as configured but does not redisplay the full value.

Retries and Idempotency

Transient failures — timeouts, connection errors, HTTP 5xx, or 429 responses — are retried automatically, up to 3 attempts with increasing delay. Permanent failures (other non-2xx responses, blocked hosts) are marked failed and logged.

Every delivery carries a unique message ID (msg_...) in the webhook-id header. Retries reuse the same message ID, so your endpoint may receive the same event more than once with an identical webhook-id. Treat it as an idempotency key: record the IDs you have already processed and skip duplicates.

Both successful and failed deliveries appear in the push or request audit log, and on the webhook’s Recent Deliveries list in the dashboard. Failed deliveries can be retried manually from the UI.

Security Notes

A few implementation details worth mentioning:

• HTTPS only. HTTP endpoints are rejected at configuration time.
• SSRF protection. Private and loopback destinations (localhost, internal IPs) are blocked to reduce server-side request forgery risk.
• Metadata only. The security-by-design principle here is straightforward: webhooks tell your system that something happened, not what the secret was. This means a compromised webhook endpoint cannot leak secret content.
• Audit trail. Webhook delivery events are recorded alongside push and request lifecycle events in the existing audit log.

Where This Might Not Be the Right Fit

Webhooks are currently available on the hosted service (pwpush.com) for Pro plans only. If you are running a self-hosted deployment, webhooks are not yet available — that is on the roadmap.

Webhook deliveries are asynchronous and best-effort with retries. If your integration requires guaranteed, exactly-once delivery with strict ordering, webhooks alone may not be sufficient — you would want to combine them with periodic API polling as a consistency check.

Also, webhooks deliver metadata, not content. If your workflow requires the actual push payload or request response, you will need a follow-up API call to retrieve it. This is intentional — it keeps the security surface of webhooks narrow.

Availability

Webhooks are available now on pwpush.com for Pro plans, currently in beta. We are still refining the experience and welcome feedback.

Full documentation is available at docs.pwpush.com/docs/webhooks/.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

The Gap Between Access Control and Identity Verification

Password Pusher has always offered two ways to restrict access to a secret link: view limits and passphrases. Both serve their purpose, but neither answers a more fundamental question — is the person opening this link actually the person I sent it to?

A passphrase is a shared secret. Anyone who has it can use it. It has to be communicated through a separate channel, and it can be forwarded just as easily as the link itself. View limits cap how many times a link can be opened, but they don’t distinguish between the intended recipient and someone who happened to get the forwarded link first.

Authenticated Recipients addresses this directly. Instead of proving you have a code, you prove you are the intended recipient — by demonstrating control of the email address the sender authorized.

How It Works

When you create a push using Auto-Dispatch (which emails the secret link to recipients on your behalf), a new option appears: Require Email Verification.

With this enabled, anyone who opens the secret link sees an email challenge before the payload is revealed:

1. The recipient enters their email address.
2. If the email matches the authorized recipient list, a 6-digit one-time code is sent.
3. The recipient enters the code to unlock the secret.
4. The code is single-use and expires quickly.

If the email doesn’t match the allowlist, the same interface is shown — but no code is sent. This is deliberate: no information leaks about who was supposed to receive the secret, and there’s no way to enumerate the recipient list by probing.

What This Means for Compliance

For organizations that need to demonstrate controlled delivery of sensitive information, the audit trail now includes identity verification events alongside view events. The difference matters: previously, audit logs could show that someone viewed a secret at a given time from a given IP. Now they can show that the viewer proved their identity before accessing the content.

This is relevant for security questionnaires, internal compliance policies, and any workflow where “prove it was delivered to the right person” is a requirement — not just “prove it was delivered.”

Stacking With Existing Controls

Authenticated Recipients integrates with the features you already use:

• Auto-Dispatch. The recipient list comes from the same emails you’re already sending to. The verification checkbox is a single additional option on the push creation form.
• Passphrases. Both controls can be active simultaneously. The recipient verifies their email and enters a passphrase. The flow handles each step in sequence.
• Requests. This works for credential requests too — when someone submits a response to your request, they verify their identity first.
• Policies. Account admins can set the default behavior, enforce verification on all pushes, or leave it as a per-push decision for individual users.

Security Implementation

A few details on how the verification is built:

Where This Might Not Be the Right Fit

Authenticated Recipients requires Auto-Dispatch recipients — the feature activates when you specify email addresses for automatic delivery. If you’re sharing a link manually (copying it from the preview page and pasting it into a chat message or your own email), there’s no recipient list to verify against. In that case, passphrases remain the access control mechanism.

The verification also depends on email delivery. If your recipient’s email is delayed or filtered to spam, they’ll need to wait for the code to arrive. For time-sensitive scenarios where the recipient is standing next to you, a passphrase is faster.

Availability

Authenticated Recipients is available now on pwpush.com for Premium, Pro, and Enterprise plans. It will be included in the next Self-Hosted Pro release.

This has been one of our most requested features — the original community request dates back to early 2024. I’m glad it’s here.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

This is a Feature Pipeline release: auto-dispatch has been available on pwpush.com as part of the Pro edition, and is now included in OSS Password Pusher for all self-hosted deployments.

The Copy-Paste Problem

Every secret-sharing tool works roughly the same way: you create a self-destructing link, copy it, and then paste it into an email or chat message to send it along.

That last step — the manual copy-paste — has always been a minor annoyance for individual users and a real bottleneck for teams and MSPs who share credentials dozens of times a day. It also means the delivery method is entirely outside the application, so there’s no audit trail of who the link was sent to, only who viewed it.

v2.9.0 closes that gap.

What Is Auto-Dispatch?

When you create a push, you can now enter one or more recipient email addresses directly in the form. OSS Password Pusher will email the secret link to each recipient on your behalf, with a clear message explaining what it is, how long it lasts, and what to expect.

A few things worth noting:

• Up to 5 recipients per push. You can send to multiple people at once, comma-separated.
• Language selection. Choose the language for the email and the secret link page. This is useful when your recipients speak a different language — Password Pusher supports over 30 locales.
• Available on all push types. Text pushes, file pushes, URL pushes and QR pushes all support auto-dispatch.
• Works from the preview page too. Forgot to add recipients when creating? You can send the email from the push preview page after creation.

What Does the Recipient See?

Recipients receive an email with the secret link, who sent it, how long the link is valid, and a note about passphrases if one was set. The email is clean and straightforward — no marketing, no branding distractions.

Full Audit Trail

Every auto-dispatch action is recorded in the push audit log. You can see:

• When the email was queued
• Who it was sent to
• The delivery status: pending, processing, completed, partially failed, or failed
• Any error messages if delivery didn’t succeed

This is important for compliance and accountability. Previously, if you shared a link via email manually, Password Pusher had no record of who you sent it to — only who eventually viewed it. Now, the full lifecycle is tracked: creation → email dispatch → each view → expiration.

How Does It Work Under the Hood?

Auto-dispatch activates automatically when SMTP is configured on your instance. If your instance can send email, the auto-dispatch fields appear in the push creation form for signed-in users.

When a push with recipients is created, the application enqueues a background job that delivers one email per recipient. The job has built-in retry logic for transient SMTP failures.

There’s a configurable daily limit per user (default: 500 emails/day) to prevent abuse, and you can disable the feature entirely if you don’t want it.

Configuration

Two new environment variables:

Or in settings.yml:

notify_by_email:
  enabled: true       # Set to false to fully disable
  daily_limit: 500    # Set to 0 to block sends, null for unlimited

For the full configuration reference, see the Notify by Email documentation.

API Support

The JSON API v2 supports auto-dispatch in two ways:

1. On push creation — include notify_emails_to and optional notify_emails_to_locale:

curl -X POST "https://your-instance.com/api/v2/pushes.json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "push": {
      "payload": "my-secret-password",
      "expire_after_days": 3,
      "expire_after_views": 5,
      "notify_emails_to": "alice@example.com, bob@example.com",
      "notify_emails_to_locale": "fr"
    }
  }'

2. For existing pushes — send notifications after creation:

curl -X POST "https://your-instance.com/api/v2/pushes/YOUR_URL_TOKEN/notify_emails" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "notify_emails_to": "alice@example.com",
    "notify_emails_to_locale": "en"
  }'

The audit log endpoint also returns email dispatch events, so you can programmatically check delivery status.

For teams and MSPs who script their credential sharing workflows, this is a meaningful improvement: you can now create a push and deliver it to the recipient in a single API call.

Feature Pipeline

Auto-dispatch has been part of the Pro edition on pwpush.com for some time. With v2.9.0, it’s now included in OSS Password Pusher for all self-hosted deployments.

This is how the Feature Pipeline works: Pro subscribers on pwpush.com get early access to new features, and over time, those features move into the open-source codebase. Subscribers fund the development; OSS Password Pusher is the eventual beneficiary.

If you’re running a self-hosted instance, upgrade to v2.9.0 and make sure SMTP is configured — the feature activates automatically from there.

Where This Might Not Be the Right Fit

Auto-dispatch sends emails through your instance’s configured SMTP server. If your SMTP provider has strict sending limits (e.g., Gmail’s 500/day for personal accounts), the daily cap setting lets you stay within those limits. For high-volume use cases, a transactional email provider like SendGrid or Amazon SES is recommended.

Also, auto-dispatch requires signed-in users — anonymous pushes can’t trigger email notifications, by design. This prevents the feature from being used for spam.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

The Problem Everyone Knows About

If you work in IT, run a web agency, manage infrastructure for clients, or handle onboarding for any kind of service — you’ve been in this situation. You need a password from someone. A client, a vendor, a new hire, a colleague in another department.

So you ask for it. And what happens next is almost always the same.

They email it to you. Or they paste it into a Slack message. Or a Teams chat. Or a shared Google Doc. Or — and this one still surprises me — a text message.

That password now lives in a system designed to keep messages forever. Searchable, forwardable, sitting in logs and backups long after anyone remembers it exists. Every compliance framework tells you not to do this. Everyone does it anyway, because there hasn’t been a simple alternative.

What “Securely” Actually Means Here

There are a few properties that matter when collecting credentials from someone:

• Encrypted in transit and at rest. The password should never be visible as plain text in a database, an inbox, or a log file.
• Self-destructing. Once you’ve retrieved the credential, the data should be permanently deleted. Not archived. Not soft-deleted. Gone.
• Audit-logged. You should know exactly when the credential was submitted and when it was retrieved — for your own records and for compliance.
• No account required for the sender. If collecting a password requires your client to sign up for a service, install an app, or figure out PGP, they’ll just email it to you instead.

That last point is the one most solutions get wrong.

The Old Way vs. the New Way

Password manager sharing is secure, but it only works when both parties use the same manager — which almost never happens across company boundaries. Request links solve the cross-organization problem.

How Requests Work in Password Pusher

Requests flip the direction of Password Pusher’s core mechanic. Instead of creating a secret and sending a link to a recipient, you create a request and send the link to the person who has the secret.

Here’s the flow:

1. You create a Request. Give it a name (e.g., “Staging server credentials”), set expiry rules, and optionally add your branding.
2. You send the Request link. Email it, message it, put it in a ticket — the link itself contains no sensitive data.
3. Your client opens the link and submits their credentials. The submission is encrypted before it’s stored. No account needed.
4. You get notified and retrieve the submission. Every access is logged. The data self-destructs after your configured limits.

The entire exchange is encrypted with AES-256, audit-logged from creation through retrieval, and permanently deleted once it expires.

Where This Fits in Practice

The most common use cases we see:

• MSPs and IT service providers collecting login credentials during client onboarding
• Web agencies gathering CMS, hosting, and DNS credentials from new clients
• Internal IT requesting WiFi passwords, VPN configs, or service account credentials from other departments
• HR and finance collecting sensitive employee information during onboarding
• Compliance teams receiving credentials for vendor assessments

If you’re already using Password Pusher to send passwords, Requests are the other half of the workflow.

What About Other Options?

A few purpose-built tools have appeared for credential collection — CredentialShare, SecureBin, and various WordPress plugins. They tend to focus narrowly on the intake form and skip the broader workflow: team management, custom domains, white-label branding, file attachments, API access, and self-hosted deployment.

Password Pusher Requests include all of those, and they work consistently whether you’re on the hosted service at pwpush.com or running a self-hosted instance on your own infrastructure.

Where Requests May Not Be the Right Fit

If you need ongoing, persistent access to a credential — like a shared service account password that multiple team members use daily — a password manager with a shared vault is the right tool. Requests are designed for one-time handoffs, not persistent storage.

If your organization requires SAML-based SSO for every tool in the stack, note that Password Pusher supports OIDC (OAuth2) on the self-hosted Enterprise tier. SAML is not currently supported on any tier.

Getting Started

You can create a Request right now with a free account. The recipient doesn’t need an account — they just open the link and submit.

For teams that need audit trails, branding, and custom domains, those are available on Pro plans. For organizations that need to keep everything on their own infrastructure, Self-Hosted Pro includes Requests with full API access.

The next time someone asks “just email me the password” — send them a Request link instead.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

Those guides aren’t wrong. But they’re answering the wrong question.

The better question is: should sensitive information be in an email at all?

The Short Answer

No. Don’t put the password in the email. Put it behind a one-time link that self-destructs after it’s been read. Send that link through email — or Slack, or Teams, or text. The sensitive data never touches anyone’s inbox.

That’s it. That’s the whole approach. If you want to get started right now, go to pwpush.com, paste your secret, and you’ll have a link in about five seconds. No account required.

If you want to understand why this is better, keep reading.

What’s Wrong With Password Protected Email

Password-protecting an email sounds secure. The problem is what happens after the recipient opens it.

The credential persists. Once your recipient reads the email, that password now sits in their inbox — indefinitely. It’s in your Sent folder too. Both are backed up, synced across devices, and archived by your email provider. That one credential you sent at 3pm on a Tuesday now exists in a half-dozen places, none of which you control.

Gmail Confidential Mode isn’t encryption. Google’s own documentation acknowledges this. The recipient can’t forward the email, but they can screenshot it. Google can still scan the contents. And the “expiration” just removes access to the email — it doesn’t delete the data from Google’s servers.

The password-for-the-password problem. If you encrypt an email, you need to get the decryption password to the recipient somehow. Most people send it in a separate email. So now you have two emails, both in inboxes, both persistent — and anyone who compromises the inbox gets both.

Forwarding and screenshots. Even with access controls, you can’t prevent someone from copying the text and pasting it somewhere else. The fundamental issue isn’t access control — it’s that email is a persistent medium, and credentials shouldn’t persist.

The One-Time Link Approach

Instead of trying to make email secure, take the sensitive data out of email entirely.

1. Put the credential behind a one-time link
2. Send the link through whatever channel you’d normally use — email, Slack, Teams, text
3. The recipient clicks the link and sees the credential
4. The link self-destructs. The data is deleted.

The email still exists in both inboxes, sure. But it contains a link to something that no longer exists. Anyone who finds that email later — whether through a breach, a forwarded thread, or an old backup — gets nothing.

How Password Pusher Works

Password Pusher is built specifically for this:

• Paste your secret at pwpush.com and set a view limit and expiration
• Get a one-time link — send it however you want
• Recipient clicks the link and sees the secret
• The data self-destructs after the view limit or time limit is reached

No account required. No software to install — for you or the recipient.

A few extras that matter: a retrieval step that prevents URL preview bots (Slack, Teams, iMessage) from consuming views before your recipient sees them. Passphrase protection for an extra layer. An audit trail showing when links were accessed. And auto-dispatch to email the link directly to the recipient on your behalf.

Password Pusher has been in production since 2011 — over fourteen years. The security-critical code is fully open source and auditable on GitHub. Over 100 million secrets shared. You can use it for free, or get Pro features like team collaboration, custom domains, and white-label branding for your organization.

Quick Recap

The safest email is the one that doesn’t contain the secret.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

Most of the time, that’s not what you need. You need to get a file to someone securely, know when they’ve accessed it, and have the whole thing disappear when it’s done.

The Quick Answer

Password Pusher lets you attach files to a self-destructing link. Upload the file, set an expiration, share the link. The recipient clicks it, downloads the file, and the link expires after the view limit or time limit you set. No account required — for you or the recipient.

If that’s enough to get started, go to pwpush.com and try it. No signup needed.

If you want to understand the full feature set, keep reading.

How File Sharing Works in Password Pusher

The workflow is the same whether you’re sharing a text password or a file — or both at the same time.

1. Go to pwpush.com and create a new push
2. Attach one or more files alongside any text or notes you want to include
3. Set your expiration — how many views and how many days before the data is deleted
4. Get your link — a unique, one-time URL you can send through email, Slack, Teams, or any other channel
5. Share it — your recipient clicks the link and downloads the files

After the view limit or time limit is reached, the files and any associated text are deleted. Not archived somewhere. Deleted. The link goes dead, and anyone who finds it later gets nothing.

You can also add a passphrase so the recipient needs both the link and a separate password to access the files — useful when you’re sending something particularly sensitive.

Track Who Accessed Your Files

This is where Password Pusher goes beyond basic file sharing. Every push comes with a complete audit trail:

• Who opened the link — IP address and geographic location
• When they accessed it — exact timestamp
• How many times the link has been viewed
• Whether it’s still active or has expired

You can also turn on access notifications so you get alerted the moment someone opens your link. For compliance-sensitive workflows — legal, finance, healthcare, IT — knowing exactly when and where a file was accessed isn’t optional. It’s required.

And if you need to revoke access before the expiration? One click. The link dies immediately.

Why Not Just Use Dropbox or Google Drive?

Those platforms are great for ongoing collaboration. But they’re designed for files that stick around — shared folders, persistent access, version histories. That’s the opposite of what you want when sharing sensitive documents with a client or contractor.

When you share a file through a cloud drive:

• The file persists in shared folders, recent files, and backups — indefinitely
• Access is ongoing unless you remember to revoke it
• Recipients need accounts on the same platform
• No audit trail for individual file access at the link level

Password Pusher is built for the other use case: ad-hoc, temporary file delivery where the file should stop existing after it’s been received.

Send a contract draft to a client. Deliver API credentials with supporting documentation. Share tax documents with your accountant. Get configuration files to a contractor. In all of these cases, the file needs to get there, the recipient needs to confirm receipt, and then the file should be gone.

Built for Teams and Organizations

If you’re sharing files across a team, Password Pusher Pro adds the features organizations need:

• Custom domains — share links from your own domain instead of pwpush.com
• White-label branding — your logo, your colors, your messaging. Recipients see your brand, not ours
• Team dashboards — shared visibility into all pushes across your organization
• Workspace policies — enforce expiration limits, passphrase requirements, and other security rules organization-wide
• API and CLI — automate file distribution through your existing workflows

Pro is available as a hosted service on pwpush.com — with dedicated EU and US data regions — or as a self-hosted license for organizations that want files on their own infrastructure.

Getting Started

Text and password sharing on pwpush.com is free — no account required. File sharing is available with Premium and Pro subscriptions, starting at $19/month.

If you’d rather self-host, the open source edition includes file sharing out of the box. Deploy it on your own infrastructure and start sharing files immediately.

The platform has been in production for over fourteen years — AES-256 encryption, more than 100 million secrets shared, and a fully auditable open source codebase. No portal. No enterprise contract.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

And almost everybody does it the same way: paste it into an email, drop it in Slack, or text it.

It works. Until it doesn’t.

The Problem With How We Share Passwords

When you send a password through email or a messaging app, that credential now lives in multiple places indefinitely — your sent folder, their inbox, the messaging server’s database, backups, email archives, possibly synced to multiple devices. That one password has gone from existing in one place to potentially dozens.

This isn’t a theoretical risk. Credential exposure through persistent messages is one of the top vectors in data breaches. An old Slack DM from 2023 containing a database password is just as dangerous in 2026 if that password hasn’t been rotated — and let’s be honest, it probably hasn’t been.

The best way to securely share passwords is to make sure they don’t persist after they’ve been received.

One-Time Links: The Simple Answer

The concept is straightforward: instead of sending the password directly, you generate a link that contains the password. The recipient clicks the link, sees the password, and the link self-destructs. Gone. No copies lingering in inboxes or message histories.

This is the best way to send passwords whether you’re sharing them with colleagues, clients, or anyone else — because the credential simply stops existing after it’s been read.

What makes this better than the alternatives:

• No persistence. The password doesn’t live in email archives, chat logs, or backup tapes.
• No account required. The recipient doesn’t need to install anything or create an account. They click a link.
• Audit trail. You can see when the link was opened, how many times, and whether it expired unused.
• Works everywhere. Send the link through whatever channel you already use — email, Slack, Teams, text. The channel is just the delivery mechanism. The credential itself is behind the one-time link.

This last point matters a lot when you’re sharing passwords with clients. Your client doesn’t want to install your company’s password manager. They don’t want to create an account on a tool they’ll use once. They want to click a link and get the credential. Done.

How Password Pusher Works

Password Pusher is built specifically for this. Here’s the workflow:

1. Go to pwpush.com
2. Paste your password or secret
3. Set how many views and how many days before it expires
4. Click “Push it!” — you get a unique link
5. Send that link to your recipient

That’s it. When they open the link, they see the password. After the view limit or time limit is reached, the data is deleted. Not archived. Deleted.

A few things that matter in practice:

Retrieval step. When you send a link via Slack, Teams, or iMessage, URL preview bots will automatically fetch the link before the recipient even sees it. If the tool counts that fetch as a “view,” the secret might already be gone. Password Pusher includes a one-click retrieval step that stops bots from burning your links.

Passphrase protection. For particularly sensitive credentials, you can add a passphrase. The recipient needs both the link and the passphrase to see the content — a clean two-factor delivery.

Auto-dispatch. If you’d rather not deal with sending the link yourself, Password Pusher can email it directly to the recipient on your behalf.

Why 345,000+ People Use It Every Month

Password Pusher has been in production since 2011. Over fourteen years. That’s a long time for a security tool — and longevity matters when you’re trusting something with credentials.

The core application is fully open source on GitHub. Every line of the security-critical code — the encryption (AES-GCM 256-bit), the data handling, the expiry logic, the audit logging — is auditable by anyone. Over 100 million secrets have been shared through the platform.

You can use it for free at pwpush.com with no account required. Or you can self-host it on your own infrastructure if you prefer to keep everything in-house.

Apnotic and Pro Subscriptions

In 2024, I founded Apnotic, LLC to put a proper company behind Password Pusher. The project had grown well beyond a side project, and it needed the support structure to match.

Password Pusher Pro is the subscription tier for teams and organizations. It adds team collaboration, custom domains, white-label branding, file sharing, and workspace-level policies — the features that matter when you’re using Password Pusher across a team rather than individually.

Pro is available both as a hosted service on pwpush.com — with dedicated EU and US data regions — and as a self-hosted license for organizations that need credentials on their own infrastructure.

The free tier isn’t going anywhere. It’s the foundation of the project and always will be. Pro is for the organizations that need more.

Peter Giacomo Lombardo — Apnotic, LLC

It’s the simplest way to share a password without leaving it sitting in an inbox, a chat log, or a shared document forever.

How One-Time Password Links Work

The concept has three parts:

1. You create the link. Paste your password into a tool that generates a unique URL. You set how many times the link can be viewed and how long it should stay active.
2. You send the link. Through email, Slack, Teams, text — whatever channel you’d normally use. The password isn’t in the message. Just the link.
3. The link self-destructs. After the recipient views it — or after the time limit expires — the data behind the link is deleted. The URL goes dead permanently.

The key difference from sending a password directly: the credential doesn’t persist. An email with a password in it is searchable, forwardable, and backed up indefinitely. An email with a one-time link in it becomes worthless the moment the link expires.

Why Use a One-Time Link Instead of Sending the Password Directly

Every time you paste a credential into an email or chat message, that credential now exists in multiple places you don’t control — sent folders, recipient inboxes, message server databases, cloud backups, synced devices. One credential, potentially dozens of copies.

A one-time password link changes the equation:

• The password lives in one place — behind the link — until it’s viewed or expires
• You control the lifecycle — set view limits (1 view, 5 views, whatever you need) and a time window (hours, days, or weeks)
• You get an audit trail — know when the link was opened, from where, and how many times
• The recipient doesn’t need an account — they click a link, that’s it
• You can revoke it early — if you sent the link to the wrong person, kill it before they open it

This works equally well for sharing credentials with colleagues, sending temporary passwords to clients, or distributing API keys to contractors. The recipient gets what they need. The credential doesn’t outlive its purpose.

How to Create a One-Time Password Link

Password Pusher has been doing this since 2011. Here’s the workflow:

1. Go to pwpush.com — no account required
2. Paste your password, API key, or any text you need to share
3. Set your view limit (how many times the link can be opened) and expiration (how many days or hours before it’s deleted regardless)
4. Optionally add a passphrase — the recipient will need both the link and the passphrase to see the content
5. Click “Push it!” and copy the generated link
6. Send the link to your recipient however you want

When they open the link, they see the credential. After the view limit or time limit is reached, the data is permanently deleted.

What About URL Preview Bots?

This is a real problem that most one-time sharing tools ignore. When you send a link through Slack, Microsoft Teams, or iMessage, those platforms automatically fetch the URL to generate a preview. If the tool counts that fetch as a “view,” the password might be consumed before the recipient ever sees it.

Password Pusher handles this with a one-click retrieval step. When someone opens a push link, they see a landing page first — they have to click a button to reveal the content. Bots don’t click buttons. The recipient does.

Temporary Passwords and Short-Lived Credentials

One-time password links are especially useful for temporary passwords — credentials that only need to exist long enough to get someone logged in.

Common use cases:

• New employee onboarding — send initial login credentials that expire after first use
• Client handoffs — share staging server access or admin passwords for a project deliverable
• IT support — distribute temporary passwords for password resets
• Vendor access — give a contractor credentials for a specific system, knowing the link dies after they’ve used it

Set the view limit to 1 and the expiration to 24 hours, and you’ve created a credential that quite literally cannot persist beyond its intended purpose.

Beyond Text — Files, URLs, and More

Password Pusher isn’t limited to text passwords. You can attach files alongside your push — share a credential document, a configuration file, or an SSH key, all behind the same self-destructing link. You can also push URLs and QR codes with the same expiration controls.

File sharing requires a Premium or Pro subscription on the hosted service. If you self-host the open source edition, file sharing is included out of the box.

Open Source and Fourteen Years in Production

Password Pusher has been running since 2011. The security-critical code — AES-256 encryption, data handling, expiry logic, audit logging — is fully open source and auditable on GitHub. Over 100 million secrets shared to date.

The free tier on pwpush.com handles one-time password links with no account required. Pro subscriptions add team collaboration, custom domains, white-label branding, and workspace policies for organizations. Available hosted — with dedicated EU and US data regions — or self-hosted on your own infrastructure.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

For a while now, we’ve been noticing something in our traffic data: a lot of managed service providers already use Password Pusher.

Referral traffic from ConnectWise, Kaseya, IT Glue, Atlassian — MSP tools are consistently some of our top traffic sources. It makes sense. If you’re an MSP handing off WiFi passwords, admin credentials, or license keys to clients every day, you need a way to do that without leaving those credentials sitting permanently in a ticket history or email thread.

What we hadn’t done is acknowledge that directly on the site. Until now.

What’s New

We’ve launched a dedicated MSP page that speaks directly to how managed service providers use Password Pusher — the workflow, the compliance angle, and the specific features that matter most for credential delivery at scale.

We’ve also built out a Partner Program for MSPs and IT services companies who want to resell Password Pusher Pro self-hosted licenses to their clients.

The Partner Program

The mechanics are straightforward:

• Volume discounts from 30% to 50% off self-hosted Pro licenses, based on your lifetime license count. Your discount tier never goes down.
• Free NFR license — one free Advanced-tier license for your own internal use, granted automatically when you’re accepted as a partner.
• Automatic discount application — no special codes or manual processes. Your discount is applied at checkout based on your tier.

The idea is simple: use Password Pusher internally, know it works, and offer it to your clients with margins that make sense for your business.

Why This Matters for MSPs

The credential sharing problem in the MSP world is well understood. Passwords end up in PSA ticket notes, email threads, Slack messages — places where they persist indefinitely and are searchable by anyone with access.

Beyond the obvious security risk, there’s a growing compliance angle. Cyber insurance underwriters are increasingly asking MSPs about per-client credential isolation and documented delivery processes. Having an audit trail that shows a credential was delivered via an expiring link, viewed once, and automatically destroyed is exactly the kind of evidence that satisfies those questions.

Password Pusher handles this with self-destructing links, full lifecycle audit logging, optional passphrase protection, and one-click retrieval to prevent URL scanners from consuming views. For MSPs doing volume, Auto-Dispatch emails the secure link directly to the client — no copy-paste required.

And for MSPs with strict compliance requirements, the self-hosted option puts everything inside your own infrastructure. Your SOC 2, your controls, your data.

Getting Started

If you’re an MSP already using Password Pusher, the Partner Program is worth a look — especially if you’re deploying self-hosted instances for clients.

If you’re new to Password Pusher, the free tier on pwpush.com is the fastest way to try it. No credit card, no signup required for basic pushes.

Either way, the new MSP page has the full picture of how it all fits together for managed service providers.

Peter Giacomo Lombardo — Apnotic, LLC

The communication around it wasn’t great either. Fast Company covered the backlash, specifically calling out the “$1.65/month billed annually” framing when there’s no monthly billing option. That’s the kind of pricing trick that erodes trust, especially from a company that built its reputation on transparency.

Since then, I’ve watched a steady stream of people looking for Bitwarden Send alternatives. Which makes sense — if you were using Bitwarden primarily for Send (their secure sharing feature), a 98% price increase on what was already a secondary feature is a reasonable reason to look around.

I built Password Pusher, so I’m obviously not a neutral party here. But I’ve been building secure sharing tools since 2011 and I think I can offer some useful perspective on what to actually evaluate — regardless of where you end up.

The Price Hike Isn’t Really the Problem

Look, $20/year is still cheap software. If Bitwarden Send did everything you needed, the price increase alone probably wouldn’t be worth switching over.

The real question the price hike forces is: should you be paying for an entire password manager just to share secrets?

Bitwarden is a solid password manager. But Send is a feature inside that password manager — not a standalone product. Its roadmap, its priorities, its development resources are all driven by the password management use case. Sharing is secondary.

That’s not a knock on Bitwarden. It’s just the reality of how product development works. When you need a screwdriver, buying a whole toolbox works — but you’re paying for a lot of tools you don’t need.

And the price hike is part of a broader pattern that has the community paying attention. New CEO with private equity experience. “Always free” quietly removed from the website. Company values like “Transparency” and “Inclusion” scrubbed. People in the Bitwarden subreddit are drawing direct comparisons to the LastPass trajectory, and I can’t say those concerns are unfounded.

What Actually Matters in a Secure Sharing Tool

If you’re evaluating alternatives, here’s what I’d focus on:

Does it require an account to send? Most people sharing a secret need to do it right now. If the tool requires signup and login before you can share anything, that’s friction at exactly the wrong moment. Bitwarden Send requires a Bitwarden account. Some alternatives don’t.

What’s the expiry model? You want granular control over both view limits and time limits. Bitwarden Send caps at 31 days maximum. Some tools go longer. For most use cases, the more control you have over the lifecycle of a shared secret, the better.

Is there an audit trail? If you’re sharing credentials in a business context, you need to know: was this link opened? When? How many times? Bitwarden restricts audit logging to their Teams and Enterprise plans. For a tool focused on secure distribution, per-item audit logging should be the baseline — not a premium upsell.

Can it be self-hosted? If you’re in a regulated industry or just prefer to keep secrets on your own infrastructure, self-hosting matters. Both Bitwarden and some alternatives offer this — but the depth of self-hosted features varies widely.

Does it handle URL preview bots? This one gets overlooked. When you send a link via Slack, Teams, or iMessage, URL preview bots fetch that link before the recipient ever sees it. If the tool counts that bot fetch as a “view,” your recipient might find the secret already expired. A good sharing tool has a retrieval step or other mechanism to prevent this.

Where Password Pusher Fits

Password Pusher is purpose-built for exactly this use case — secure, temporary sharing of sensitive information. It’s been in production since 2011, it’s fully open source, and it’s handled over 100 million secrets to date.

No account required to send. Per-push audit logging on every tier. View limits, time limits, passphrase protection, and a one-click retrieval step that prevents bots from burning your links. Self-hosted or SaaS with dedicated EU and US data regions.

I wrote a detailed comparison page that puts Password Pusher and Bitwarden Send side by side — feature for feature — including the areas where Bitwarden is genuinely stronger (like their end-to-end encryption model). I’d encourage you to take a look:

Password Pusher vs. Bitwarden Send — Full Comparison →

One More Thing

Price hikes have a way of forcing useful conversations. If the Bitwarden increase made you actually evaluate what you need from a sharing tool, that’s a good outcome regardless of what you choose.

My hope is that this post helps a few people make a more informed decision. There are several solid options out there. Password Pusher is one of them, and it’s the one I’ve spent the last 14+ years building to be the best at this specific job.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

A text input. Some encryption. A submit button. That was it. I pushed it to production, open-sourced the code, and went back to my day job. I didn’t think about it much after that.

But someone used it. And then someone else did. And then a few more.

“Go Ahead. Email Another Password.” That was the tagline. That was the whole pitch. The product was barely a product — it was a reaction to a problem that annoyed me. People were emailing passwords in plain text. So I built the smallest thing that could fix that.

Then a strange thing started happening.

See that flat line from 2012 to 2014? That’s three years of almost nothing. Then a slow curve upward. Not fast. Not in any way that would make a headline. Just — every month, a little more. More Docker pulls. More people I’d never heard of, at companies I’d never heard of, quietly using this thing I built on a weekend.

Year after year. I’d add a feature. Fix a bug. Add another feature. The backlog grew. Feature requests started waiting six months. Then a year. Then longer.

And at some point — I don’t remember the exact moment — but sometime in late 2023-2024 I had to make a decision.

Option one: keep the pace. Hobby project. A few features a year. Nothing wrong with that.

Option two: find a way to make this thing self-sufficient. Work on it properly. But on my terms.

I went with option two.

Now here’s the part where most founders say they raised a round. Pitched VCs. Built a deck. Got a term sheet.

I didn’t do any of that.

Instead, I built a feature pipeline. Premium features for subscribers, with those features rolling into the open-source version over time. Customers fund development. Development benefits everyone. No investors, no debt, no one to answer to except the people using the product.

That became Apnotic.

And today — fourteen years after that weekend — we have 345K monthly active users. 50M+ Docker downloads. Over 100 million secrets shared. 400 paying customers. Healthy recurring revenue. A team of two, an advisor, and fourteen years of work that I genuinely enjoy showing up to every day.

All from a text input. Some encryption. And a submit button.

We know you have choices. There are alternatives and competitors.

Our main criticism of many of them isn’t features—it’s price. Some charge up to $30/user/month. Others charge per push and charge for API access. How can security become the default when adoption is that complicated and expensive? That kind of pricing shuts out smaller teams and orgs that need it most.

Apnotic is a small, dedicated team. We have open source roots, no venture funding, no debt, and we’re profitable. No outside investors or pressures—just a long history of building Password Pusher (since 2011) and a focus on making a sincere, honest, and secure product.

We believe these tools should be priced so that entire organizations can have access—not just the few who use them every day. That’s the position we’re coming from.

Self-Hosted Pricing

We priced Self-Hosted with one goal: let you roll the tool out to your entire organization without per-user sticker shock with all the features you need out of the box.

We don’t charge for every user. Each plan includes a base number of seats: Starter (5), Advanced (25), and Enterprise (50). Need more than the base? We charge for extra seats—but not at competitor rates. Additional seats start at $1/user/month and go down on larger plans.

What’s more, we never limit pushes or requests, and API access is always included.

With Self-Hosted Password Pusher Pro, your data is yours. We even declare this in the EULA:

To be absolutely clear: Apnotic has no ability to access Your Data, and we never will. Your sensitive information, passwords, user content, and all other data stored within your self-hosted deployment remain completely private and inaccessible to Apnotic. We cannot see it, we do not want to see it, and we have designed the Software specifically to ensure that your data stays within your control at all times.

We hope you see the same value we do in this approach. As always, we’ll keep listening to the community and evolving. Password Pusher is what it is today because of the feedback, suggestions, and ideas you’ve shared over the years.

See Self-Hosted pricing at the links below. Where you purchase determines your customer data residency:

• US — us.pwpush.com
• EU — eu.pwpush.com (GDPR compliant)

Peter Giacomo Lombardo

Founder & Principal, Apnotic · Creators of Password Pusher

A Single German IP

For over a year, a single IP from Germany has been generating 8,000–10,000 anonymous pushes daily on pwpush.com, far exceeding the activity of any other single IP. Initially, I wondered if this was spam or abuse, but it could also have been a legitimate automated use case—who’s to say? With no complaints or harm reported, I let it slide.

Then, a few weeks ago, this IP ramped up to 90,000–100,000 pushes per day, dwarfing all other activity.

More recently, it spiked to a staggering ~200,000 pushes daily, pushing our system to its limits. This surge began to impact the experience for other users, so I had to take action.

Here’s the story, along with some context about how Password Pusher handles push expiration and what we’ve done to keep the service running smoothly.

How Push Expiration Works

In Password Pusher, pushes (and their associated requests) are designed to expire automatically based on either a view limit or a duration limit. Once a limit is reached, the secret URL self-destructs, ensuring sensitive data doesn’t linger.

• View-Based Expiration: This is straightforward. When a push reaches its final allowed view, the application displays the payload and immediately deletes the push.
• Duration-Based Expiration: This requires periodic scans. Background jobs run at intervals to identify pushes that have exceeded their duration and trigger their deletion.

To ensure no expired pushes slip through, we re-verify expiration limits whenever a viewer requests a push. If the limits are exceeded, the push is deleted on the spot, and the viewer sees an expiration message. This approach guarantees that expiration rules are always enforced, even if a background job hasn’t yet processed a push.

The Impact of the Anonymous IP

As the IP’s activity surged to ~200,000 pushes per day, our background expiration jobs took longer to complete. This increased system load and began affecting other users’ experience. While I’d like to believe there was a valid use case behind this activity, the strain it placed on Password Pusher’s infrastructure was undeniable.

Of course I can scale out more workers and increase resources but this all has a financial cost. For the single anonymous source with unknown motives, this wasn’t an option.

So to address this, I made the tough decision to block the IP—a step I’ve rarely taken. I also optimized the performance of the background expiration job and tightened API throttling to better manage high-volume usage. These changes have helped stabilize the system and ensure a smoother experience for all users.

Looking Ahead

Password Pusher is an open-source project at its core, built by the team at Apnotic to serve the community.

We’re committed to providing anonymous access and supporting diverse use cases, but we also have to prioritize the availability and performance of the service for everyone.

A Message to the Owner of that IP

If you’re the user behind this IP and have a legitimate use case, please reach out! I’d be happy to discuss how we can support your needs without compromising the experience for others.

You can contact me directly, and we’ll work to find a solution.

Alternatively, if your use case involves high-volume pushes, you might consider self-hosting your own instance of Password Pusher to better suit your needs. Here’s how you can get started:

Run Your Own Ephemeral Instance

Set up a DNS record to point to your server (e.g., pwpush.example.com).

Run the following command:

docker run -d -p "80:80" -p "443:443" --env TLS_DOMAIN=pwpush.example.com pglombardo/pwpush:latest

Browse to https://pwpush.example.com.

Or Alternatively

Use one of our production-ready Docker Compose files with persistent databases for a more robust setup.

Thank you to our amazing community for your continued support. Password Pusher thrives because of you.

Background

Up to this point, I’ve been happily working on Password Pusher since it’s inception in 2011 in my free time and it’s been greatly rewarding.

But over the last few years, popularity has grown to such a point that, because of the large backlog of work to do, feature requests have had to wait sometimes a year or more before I can even get the point of implementing them.

Some of these requests are:

• Extended Branding: More logos & custom text on more pages
• SSO & LDAP
• More Password Generator Options
• Bulk push operations
• Automatic Emailing of Pushes
• Large (>4GB) file uploads
• and a lot more…

These would be great additions to the project but have been delayed over and over again just because of the sheer number of requests and limited time.

Which Direction Forward?

So what to do?

My options are that I can either:

• Option 1: maintain the current pace with recreational coding in my free time, adding a few big features each year

or

• Option 2: find a way to to accelerate this project, make it self-sufficient and start to add the features users are asking for now

…we are going with the second option.

Feature Pipeline

The feature pipeline is a set of premium and pro features over and beyond the open-source code base that is available through subscriptions.

As development progresses, many of these premium features will periodically be moved to the open-source code base.

Organizations that subscribe get immediate access to these premium features and support open-source development.

Going forward, some newly developed features may be premium at first only, others will go straight to open-source.

This model creates a “pipeline of features” that progress from premium to open-source. It will allow me to work far more on the project and really accelerate development.

Self-Hosted: What’s Changed?

Absolutely nothing has changed but do expect more features faster in the open-source version coming soon.

Note: A self-hosted version of the Premium/Pro features (Self-Hosted Pro) is now available. See Pro Self-Hosted and Self-Hosted Pricing.

pwpush.com: What’s Changed?

You get a ton of new features immediately (without a subscription).

And for those who want to subscribe, there are even more features aimed at professionals and teams. Read about them here.

But there is one feature that is now subscription limited that wasn’t previously: file uploads. Read on for more.

pwpush.com: File Uploads

For a long time, on pwpush.com, anyone could upload files and attach them to pushes. Essentially anonymous file uploads.

It started out well but lately there has been some hints of abuse and after thinking it through, I’ve realized that anonymous file uploads pose a real risk to myself and to the project.

I really tried to keep these free but unfortunately, the risk is too great and hence are now only available to subscribers.

This only affects users of pwpush.com. Those self-hosting the application are unaffected.

Note: To utilize file uploads, you can either subscribe or self-host Password Pusher which doesn’t have any limitations on file uploads.

My apologies on this one. I really tried to keep file uploads free but unfortunately it’s just not possible.

Editions

There are now three editions of Password Pusher:

• OSS: The open source version as always available in the Github repository
• Premium: A Premium edition on pwpush.com with file uploads, a personal policy & extensive branding
• Pro: A Pro edition for teams collaboration, custom domains & team policy enforcement

Where are these editions available? Here’s a table to illustrate:

See the subscription pricing here.

Note: The Pro self-hosted option (Self-Hosted Pro) is now available. See Pro Self-Hosted and Self-Hosted Pricing.

How to Subscribe

Thank you for even considering to support the project. Pricing for the new subscriptions is here.

Summary

My hope is that the introduction of subscriptions and this new feature pipeline will allow me to build out Password Pusher to better secure you and your organizations and to to hopefully make your professional lives a little bit easier.

And ultimately, to have the open-source version as the eventual & final benefactor of new features.

Wrap Up

Thanks to the Password Pusher community for the trust, support & feedback over the years.

As always, if you have any questions, problems or feedback, feel free to contact me anytime: pglombardo at the pwpush.com domain or see the Support page for other methods.

See Also

• Pipeline New Features
• Subscription Pricing

This page explains and illustrates the new features introduced along with subscriptions and the new Feature Pipeline.

Note: These features are not yet available in the OSS edition. Read about the Feature Pipeline for more info.

For All Users

Two Factor Authentication

User accounts now include the option of enabling two-factor authentication. Make sure to download your backup codes.

Google & Microsoft Single Sign-On

Login with your Google and/or Microsoft account

Personal Policies

Set Push defaults, preferences, limits and even hide options entirely.

Multiple API Tokens

Create a Unique token for each tool that you connect with.

You can even revoke tokens now.

Multiple Workspaces

One for you, one for your day-time job and others for whatever your needs are.

Easy switch between workspaces without having to change your log in.

Set your timezone, preferred language and more.

Finally - show dates/times in your local timezone.

Premium

Premium & Pro subscribers get personalized branding and can attach files to pushes.

File Uploads

Add files to text pushes:

Or push only files:

Users receive branded pushes with files:

Logo Branding

Add a logo to your pushes.

1-Click Retrieval Step Branding

The 1-click retrieval step page can be customized to increase end-user confidence with a logo or custom text. You can even change the text of the “Click Here to Proceed” link if you wish.

Passphrase Page Branding

The passphrase page can be branded with custom text, links and a logo.

Delivery Page Branding

Customize the push delivery page according to your organization’s needs.

Expired Page Branding

Pro

Pro subscribers get everything above plus…

Custom Domain

Use your own custom domain on Pushes.

Invite the Team

Invite colleagues to collaborate and manage pushes

Team Roles

Decide who is admin and who is a member. Authorize others to set policy and to add/delete users.

Team Collaboration

View and manage all pushes created by your team

Team Policies

Enforce security policies on your team; hide or force options, set defaults

Summary

I hope you find the new features useful. As always, if you have any issues, questions or feedback, feel free to contact me anytime!

🤔 Still need something for you or your organization that you don’t see here? Let me know!

See Also

• Subscription Pricing
• Features Matrix
• Introducing the Feature Pipeline - Announcement Post