Do you store my API token?

Yes, when you use the browser-based token flow, ApifyForge encrypts and stores your scoped Apify API token in a PostgreSQL database using AES-256-GCM with a server-held encryption key. This is a deliberate trade-off for usability: it lets the dashboard run actors on your behalf without requiring you to keep a terminal open. If you would rather keep your token entirely on your own machine, the CLI flow is still available and stores nothing on ApifyForge's servers — both modes are supported, and you can choose.

The browser token flow (stored, encrypted)

When you paste a token into Settings → Apify API Token and click Save, here is exactly what happens:

1. The plaintext token is sent over HTTPS to the ApifyForge server.
2. The server encrypts it with AES-256-GCM using a 256-bit encryption key held in the TOKEN_ENCRYPTION_KEY environment variable. The key lives only in the server's environment — it is not written to the database, not logged, and not included in backups.
3. The resulting ciphertext is written to the users.encrypted_token column in PostgreSQL, formatted as ivHex:authTagHex:ciphertextHex.
4. The plaintext is immediately discarded from memory.

When the dashboard needs to run an actor, the server reads the ciphertext, decrypts it in memory using the same environment key, passes the plaintext to Apify's API as a URL parameter on run-sync-get-dataset-items, and discards the plaintext again. The plaintext is never logged, never written to a file, and never sent to any third party.

Why this is safer than it sounds: if someone exfiltrated the full PostgreSQL database, they would get ciphertext only. Without TOKEN_ENCRYPTION_KEY, the ciphertext is useless — AES-256-GCM with a 256-bit key is computationally infeasible to break. The encryption key lives only on the application server, so a database-only breach yields zero usable tokens.

Why the risk is not zero: if someone compromised the application server itself (not just the database), they would have both the ciphertext AND the key, and could decrypt tokens in memory. The mitigation is the scoped-token model: even if your token is exfiltrated, the scoped permissions limit what an attacker can do with it — read metadata, read storages, and trigger runs on your account, but not modify actors, touch billing, or create new tokens. The full scope analysis is in How do I create a scoped Apify API token for ApifyForge?.

The CLI flow (not stored)

If you prefer zero server-side storage, run npx apifyforge run <tool> instead. Your token lives only in your local APIFY_TOKEN environment variable, the CLI uses it locally to call the Apify API, and only the computed results are uploaded to your ApifyForge dashboard via HTTPS. At no point does the token transit through or get stored on ApifyForge infrastructure. Both flows produce identical results in the dashboard — the browser flow is just easier for most users because it does not require a local Node install or a terminal.

How to revoke access

You can revoke ApifyForge's access at any time in two places. Either one works independently; doing both is belt-and-braces.

In ApifyForge: open Settings → Apify API Token and click Delete token. This deletes the encrypted ciphertext from the users.encrypted_token column. ApifyForge can no longer run anything on your account after this — any in-flight run completes, but new runs fail with a 'no token configured' error and the dashboard reverts to the ConnectTokenStep state.

In Apify: open console.apify.com/settings/integrations, find the token you created (whatever name you gave it — apifyforge-dashboard is the suggested default), and click Revoke. This invalidates the token everywhere, not just in ApifyForge, which means it is the definitive off switch. Even if ApifyForge were entirely unreachable, this would still work because Apify's own API enforces the revocation.

Best practices

A few things worth doing regardless of which flow you pick:

• Create a dedicated token for ApifyForge — do not reuse your main Apify token. Use the suggested name apifyforge-dashboard so it is identifiable in your Apify audit logs.
• Set a budget alarm in your Apify account at console.apify.com/billing. This caps how much a compromised token could burn through regardless of any application-level protection. If a token ever leaks, the budget alarm stops the bleeding.
• Rotate every 90 days. Create a new scoped token, paste it into Settings (it overwrites the old one automatically), then revoke the old one in Apify.
• If you suspect a compromise, revoke immediately in Apify first, then delete in ApifyForge Settings. Revoking in Apify is the source of truth — it takes effect even if ApifyForge is unreachable.
• Never commit tokens to git. Obvious but worth saying: add .env to your .gitignore.

Your ApifyForge dashboard account is authenticated via GitHub or Google OAuth, completely separate from your Apify credentials. This decoupling means your dashboard identity and your Apify identity are linked only via the encrypted token — revoking one does not automatically revoke the other, but both paths to revocation are straightforward.

For the scope analysis of exactly what the stored token can and cannot do, see What data can ApifyForge access?. For how to fully disconnect and clear your account, see How do I disconnect my account?.

Last updated: April 14, 2026