Security

1. Our security model

Nodes2Cloud compiles your workflow into Cloudflare Worker source code and deploys it into your own account. That architectural choice is also our most significant security control:

• We are not in your data path. Records your workflows read and write move between your Worker and the services you connected. A compromise of our systems would not expose them, because they were never there.
• We store no execution data. Run history lives in your own Cloudflare resources; we fetch and render it on demand using your credential.
• The sensitive asset we do hold is credentials — the tokens needed to deploy on your behalf. Most of what follows is about protecting those.

2. How stored credentials are encrypted

• Every credential is encrypted with AES-256-GCM, an authenticated cipher, so tampering is detected as well as prevented.
• The encryption key is derived per account using HKDF-SHA256 from a master key and your account identifier. Two customers never share a key, so compromising one credential does not generalise.
• The master key exists only in the platform’s secret store. It is never written to the database, never included in a backup of the database, and never exposed to application logs. A database dump on its own is not sufficient to decrypt anything.
• Derived keys are marked non-extractable in the runtime’s cryptographic API, so application code cannot read the key material itself.
• Each encryption uses a fresh random initialisation vector.

Two access rules constrain use of those credentials in our own code:

• Decryption is confined to the deployment path. Only the services that compile, deploy, roll back or test may decrypt. No route that returns data to a browser is permitted to.
• No API endpoint returns a credential value — not even to the account that owns it. The editor shows metadata only: a name, a type, when it was added.

3. Enhanced protection: keys we cannot use

For credentials where the default is not enough, you can enable enhanced protection. A random data encryption key is generated in your browser and wrapped with a key derived either from:

• a passkey using the WebAuthn PRF extension — the key never leaves your authenticator; or
• a passphrase you choose, stretched with Argon2id.

Only the wrapped key reaches our servers. We do not hold anything capable of unwrapping it. Deploying such a credential requires you to be present to unlock it.

The trade-off is honest: if you lose the passkey or forget the passphrase, the credential is unrecoverable. We cannot reset it, because that is precisely the property you asked for.

4. Key rotation

The platform supports rotating the master key without downtime: a previous key is retained during rotation so existing credentials decrypt while being progressively re-encrypted under the new key. This lets us rotate on a schedule, and immediately if we ever suspected exposure.

5. Account and session security

• Passwords are stored only as salted hashes using a modern password-hashing function. We cannot recover your password, only reset it.
• Email verification is mandatory before an account becomes usable. Codes are six digits, stored hashed, and expire in ten minutes.
• Resetting a password revokes every existing session, so a stolen session cannot outlive the reset.
• Social sign-in with Google or GitHub is supported; OAuth tokens are encrypted at rest.
• Session cookies are HttpOnly and Secure, so JavaScript cannot read them and they never traverse plain HTTP.
• Personal access tokens are stored as SHA-256 hashes only. A database disclosure would not yield usable tokens. They are shown to you once, at creation.
• Rate limiting and bot protection are applied to authentication endpoints to blunt credential-stuffing and brute-force attempts.

6. Application security

• A strict Content Security Policy is served with the editor, with the permitted API and WebSocket origins pinned per environment. It materially limits what an injected script could do or where it could send data.
• All traffic is TLS-encrypted in transit; HTTP is redirected to HTTPS.
• Database access goes through a typed query builder with parameterised statements, which removes SQL injection as a class of bug.
• Every mutating endpoint enforces authentication and ownership checks; multi-tenant isolation is applied at the query layer rather than left to the caller.
• An append-only audit log records significant actions — deployments, credential changes, membership changes. Secret values are never written to it.
• Dependencies are monitored for published advisories and updated on a documented process.

7. Infrastructure

• The platform runs entirely on Cloudflare — Workers, D1, KV and Durable Objects — inheriting their network-level DDoS protection and WAF.
• Secrets are held in the platform secret store, never in source control, environment files or the database.
• Databases are backed up, with a documented restore and disaster-recovery procedure.
• Administrative endpoints are separately gated and are not reachable from the customer application.

8. Data handling

• Execution data is never persisted. Live debug output is relayed to your browser in real time and written nowhere.
• AI metering records exclude prompts and workflow content by design — we record that a request happened and what it cost, not what was in it. Your assistant conversation history is stored separately so you can continue it, and you can clear it at any time; see section 3.5 of the Privacy Policy.
• Account deletion purges credentials and personal content atomically once a 7-day grace period — in which a hijacked request can be cancelled — has passed. See section 12 of the Privacy Policy.
• Sub-processors receive the minimum data their function requires, and are listed in full at Sub-processors.

9. Incident response

We maintain written runbooks for credential exposure, dependency advisories and data-recovery scenarios, so that a response is not improvised under pressure. If a personal data breach occurs we will:

• contain it and revoke or rotate anything affected;
• notify the relevant supervisory authority within 72 hours where the law requires, including the Data Protection Board of India under the DPDP Act;
• notify affected users without undue delay, describing what happened, what data was involved, and what you should do; and
• publish a post-incident summary where it is useful and does not create further risk.

10. What we do not claim

We do not claim to be “100% secure”, and we would be suspicious of anyone who did. Every system has a threat model and a set of assumptions, and ours are stated above so you can judge them. Specifically:

• We are a small operation. We do not currently hold SOC 2, ISO 27001 or an equivalent third-party certification, and we will not imply otherwise.
• Default-tier credentials can be decrypted by our deployment services — that is what makes automatic deployment possible. Enhanced protection exists precisely for credentials where you do not want that.
• We depend on Cloudflare, our email provider and our payment providers. Their security posture is part of ours.
• A workflow you deploy runs with the permissions you gave it. We cannot protect you from a workflow that was designed to do something harmful.

11. Reporting a vulnerability

We welcome good-faith security research and will not pursue legal action against researchers who follow the guidelines below.

Report to security@nodes2cloud.com. Our machine- readable contact is at /.well-known/security.txt.

Please include a description of the issue, reproduction steps, and its potential impact.

What we ask:

• Test only against your own account and data.
• Do not access, modify or destroy other users’ data. If you encounter it accidentally, stop and tell us.
• Do not run denial-of-service tests, spam, or social-engineer our staff or users.
• Give us reasonable time to fix the issue before disclosing publicly — 90 days is our default, and we will usually be much faster.

What we commit to: acknowledgement within 3 business days, an assessment and remediation timeline within 10 business days, updates as we fix it, and public credit if you would like it. We do not currently run a paid bug bounty.

12. Your part

Security here is shared. The things that most reduce your risk:

• Scope credentials narrowly. A Cloudflare token limited to the account and permissions you actually need is far safer than a global one.
• Use enhanced protection for your most sensitive credentials.
• Use a unique, strong password, and keep your email account secure.
• Review connected integrations periodically and disconnect what you no longer use.
• Review generated code before you deploy it — particularly anything the AI assistant produced.
• Never put secrets in a workflow’s static configuration. Use the credential store, which is what it is for.

Security contact: security@nodes2cloud.com. Related: Privacy Policy, Sub-processors, Data Processing Addendum.