Skip to main content
DeploTeka Set up your first store

Security & Trust one-pager

For customers and prospects evaluating DeploTeka. This page describes how the platform actually handles your Shopify credentials and the little it holds about your merchants — implemented behaviour, not aspiration.
Last updated: 12 November 2026 · Operated by Fixel Pixel LLP · Security questions: security@deploteka.com · Everything else: help@deploteka.com

DeploTeka turns one Shopify app codebase into a fleet of dedicated, per-store custom-distribution apps in your own Shopify organization, delivers each app's credentials to your backend, and releases your app version to them. The security model follows from that: we automate what you would otherwise do by hand, in your accounts, at your direction — without ever holding your password or pooling credentials across customers. Limited app verification and privacy-request forwarding are described below.

What we hold, and what we never receive

Per workspace, DeploTeka holds exactly this:

  • your account email, workspace name and role;
  • a sealed copy of your Shopify dashboard sign-in session, while you are connected;
  • a sealed release login, while it is connected: a Shopify CLI sign-in you approved, with the app-management permission only;
  • sealed operational keys: the client id + client secret of each dedicated app, any release key you save for an app, and — only while a release runs — that release's automation token;
  • each dedicated app's client id, its sealed install link, the shop domain and status of each client store, and the history of every setup run and release;
  • an audit log — who did what, to which app or store, when, with what outcome; never a secret value;
  • only for apps using token delivery: the merchant's sealed offline Admin API access token, held until it has been handed to your backend and the merchant uninstalls.

Your app sends its business data to your backend. DeploTeka does not retain shopper-event analytics. Limited installation checks may make authenticated Admin API requests, and optional extension verification may fetch configured storefront pages and assets. We retain verification outcomes and proof identifiers; privacy requests are forwarded as described below.

Your Shopify credentials

  • Your password never touches us. You connect by running npx deploteka or pairing the browser extension, then log in on Shopify's own login pages. Password, captcha and one-time codes stay between you and Shopify — they never pass through DeploTeka and are never stored by us, in any form.
  • We hold a session, not a credential you typed. After you log in, the connector hands over your Partner + Dev dashboard session over TLS. It is sealed in the vault, never written to logs or rendered into pages, and used exclusively server-side for the onboarding steps that have no machine-to-machine route at Shopify: creating a dedicated app in your organization, setting it to custom distribution, producing its install link, and requesting access to a client store. Automated setup for an app also needs your explicit, recorded grant in the cabinet.
  • Shopify controls its lifetime. There is no guaranteed session lifetime. We re-verify before use; if a saved session is no longer accepted and cannot be renewed, the cabinet asks you to reconnect. An ended session pauses new store setups at the step that creates the store's app. It does not stop running stores, which run on the operational keys below, or releases made with the release login.
  • Revocation is in your hands, twice over. Disconnect in the cabinet to stop active use and record durable destruction work for the retired sealed copy; storage failures are retried without restoring access. Or log out all sessions on Shopify's side, which invalidates our copy no matter what.
  • The release login, if you connect it. A separate Shopify CLI sign-in: a workspace owner or admin starts it and approves it on Shopify's page with a one-time code, and your own Shopify CLI stays signed in. It carries the app-management permission only, so it can release versions of the apps in your organization and cannot read store data. It renews itself; each renewed copy is sealed in the vault and never written to logs or pages. It is what lets releases run from our server for every store, new ones included, with no key per store. Disconnect it on the release settings page and we stop using it and delete it.
  • No pooled "master" credentials, ever. Every client store gets its own dedicated app, created in your organization. There is no shared app and no cross-customer credential mixing — compromising or offboarding one store never exposes another.

Operational keys — there is something to revoke

  • Release keys. A key you save for an app yourself is sealed and used for that app's releases until it expires or you remove it; you created it, so we never revoke it at Shopify. Where a release has neither the release login nor a saved key, it creates a Shopify app automation token for that app through your connected session — the shortest lifetime Shopify offers, one month — and revokes it when the release ends; if the revocation cannot be confirmed, the token expires on its own.
  • Per-store access keys. Install verification and health checks use each dedicated app's own client id and client secret, created by the setup and sealed per store.
  • Per-store keys outlive the session, so they can be revoked. Rotate a dedicated app's client secret at Shopify at any time and our copy stops working. We retire our copies and record durable destruction work when you delete the store (per-store keys, that store's install links and any merchant token), on your written request, and when your workspace closes. Physical removal is retried after storage failure.

Your merchants' tokens — held in transit, not in stock

  • Token delivery, if you use it. When a merchant installs one of your dedicated apps, we receive the offline Admin API token Shopify issues, seal it and hand it to the endpoint you configured. Uninstall or token replacement retires our copy and records durable destruction work. Limited authenticated Admin API requests verify credential validity, app identity and required extension state. The basic shop-endpoint check retains status without parsing or storing the response body. We never return the token to the cabinet or log it; records contain a reference or fingerprint instead. A token your endpoint could not accept is kept, sealed, until you retry the delivery, so an outage on your side does not cost every merchant a re-install.
  • Ingress is authenticated. Every webhook from Shopify — install, uninstall, and the privacy requests about a store — is HMAC-verified against that dedicated app's secret before anything acts on it. A bad signature is rejected, and a shop that cannot be mapped to exactly one workspace is refused rather than guessed.
  • Privacy requests are forwarded, not absorbed. We hold no customer data, so a customers/data_request, customers/redact or shop/redact from Shopify is forwarded to your backend and the forwarding is audited. If your endpoint does not accept it we decline the webhook so Shopify retries, rather than letting a request disappear behind a 200.

Deleting things

  • Disconnect stops active use of the Shopify session and records durable destruction work. Owners and admins only; failed physical deletion is retried.
  • Delete a store to remove its records and retire its credentials. The owning record change and destruction work are committed together; physical ciphertext deletion is retried after storage failure, with bounded outcomes recorded. The dedicated app itself stays in your Shopify organization; it is yours.
  • A merchant uninstall retires our copy of that merchant's token and records durable destruction work before notifying your backend. Physical removal is retried and does not depend on that endpoint answering.
  • Workspace export and closure are on request, not a button. Write to privacy@deploteka.com and within 30 days we export your workspace records in a machine-readable format, close the workspace and destroy its sealed secrets, or both. Retired sealed copies remain until physical cleanup succeeds and backups containing them expire; storage or backup delays can extend that period.

Tenant isolation & minimal collection

  • Every read and write is tenant-scoped at the data-access layer. A signed-in operator can only ever see their own workspace's apps, stores, runs and keys — isolation is enforced in the query path, not just the UI.
  • Credentials are bound to their tenant cryptographically. Each secret is sealed with the owning workspace as authenticated data, so a ciphertext cannot be unsealed for a different workspace even by a bug that mixed up references.
  • We collect the minimum, and we track no one. The contact form takes a work email and three multiple-choice answers — nothing more — and the endpoint is rate-limited with validation and size caps on every field. There are no third-party analytics, advertising, or tracking scripts on the site or the cabinet: the content-security policy allows only our own origin, every page works without JavaScript, and the only cookies are a sign-in session cookie and a theme-preference cookie, both first-party.

Transport, storage & operations

  • All traffic is over TLS.
  • Every credential — session, operational keys, install links, merchant tokens — lives in a vault sealed with AES-256-GCM envelope encryption: a fresh data key per secret, wrapped by a master key that is kept out of the database and out of the backups. Plaintext is never stored, never logged, never rendered. This is how it is built; it is not a compliance certification.
  • Request bodies are not logged. Log lines come from an allowlist of fields; no secret, cookie, token or install URL can appear in one.
  • Every state change is audited — connect, disconnect, setup, release, credential delivery, forwarded privacy request, deletion — with actor, target, time and outcome. Every state-changing request is CSRF-protected.
  • Hosting: a single server at Scaleway SAS in Amsterdam, the Netherlands (EU), which also runs our own mail server. Payments go through Stripe; Cloudflare provides DNS only and carries none of our traffic. The full sub-processor list with purposes and locations is in the Privacy Policy (/legal/privacy) and the DPA (/legal/dpa).
  • Backups are scheduled every six hours, with the newest 28 copies retained. Sealed secrets stay sealed inside backups. Delayed backups or storage failures can extend retention. Recovery must preserve deletion decisions and complete pending destruction before returning restored data to use. The backup schedule alone does not prove alert delivery or a successful replacement-host recovery.

Responsible disclosure

Found something? Email security@deploteka.com. A person reads and answers, keeps you informed, and we won't pursue good-faith research conducted without harming tenants or data.

DeploTeka is not affiliated with or endorsed by Shopify. "Shopify" is a trademark of Shopify Inc.
No third-party attestation (SOC 2 / ISO 27001) is claimed; this page states only implemented behaviour.