Security and data integrity
Security & data integrity
stackferry is designed to assess and coordinate migrations without turning the project workspace into a store for production data or secrets. This page describes the controls in the current product and the responsibilities that remain with each customer.
Effective 14 July 2026 · version 2026-07-14
1. Architecture and isolation
The public web application is delivered through Netlify. Authentication, project records and server-side functions use Supabase. User and project records are protected with row-level security and project membership checks. Administrative credentials are available only to server-side functions and are not embedded in browser bundles.
Customer workspaces are logically isolated. Access to a project requires ownership or explicit project membership. Service-role access is limited to authenticated functions that need it for a defined operation.
2. Secrets and credentials
Provider credentials, GitHub private keys, Stripe keys and webhook secrets are stored as managed server-side secrets. Project records accept repository URLs and redacted metadata, not secret values. GitHub installation tokens are short-lived and minted server-side.
Customers must enter destination credentials directly into the destination provider's secure console when possible. Do not paste API keys, database passwords, payout details or private keys into descriptions, support email or ordinary project fields.
3. Repository access
The stackferry GitHub App requests read-only Metadata and Contents access. The customer chooses the account and repositories during installation and can revoke access in GitHub. The current inventory reads limited repository information needed to identify framework and infrastructure signals and does not persist a source-tree copy.
Public repositories can be inspected without an installation. Private repository requests are matched to a GitHub installation owned by the signed-in stackferry user before an installation token is created.
4. Payments
Payment details are collected on Stripe-hosted Checkout. stackferry does not receive or store full card numbers. Checkout sessions are created only by an authenticated server function, use a server-selected product and amount, and return only to approved stackferry URLs.
Stripe webhook events are accepted only after verification of the signature over the unmodified request body. Event identifiers are recorded for idempotency so repeated delivery cannot create duplicate order state transitions.
5. Data integrity and migration safety
A standard port creates an empty or schema-only target and keeps the source unchanged. Production rows, authentication identities, files and cutovers require a separate authorised plan with scope, validation and rollback evidence.
Order and workflow state changes use database constraints, timestamps and server-confirmed payment events. Compatibility findings are decision support and should be reviewed before any irreversible operation.
6. Transport, browser and operational controls
stackferry uses HTTPS in production, restrictive browser security headers, protected auth redirects and noindex controls on private application routes. Sessions use Supabase's managed authentication tokens and browser storage required for sign-in.
Dependencies, database migrations and deployment artifacts are version controlled in the private stackferry repository. Production changes are built and tested before deployment through the connected Netlify workflow.
7. Availability, backups and recovery
stackferry relies on the resilience and backup features of the selected Netlify and Supabase plans. We maintain reproducible database migrations and application builds. The standard web service does not include a bespoke uptime or recovery-time SLA unless one is stated in an order.
Customers remain responsible for independent source-repository and production-system backups. A migration plan must preserve the source and a rollback route until the destination is accepted.
8. Incident response and reporting
We investigate credible reports, contain affected access, preserve relevant evidence and notify customers or authorities where applicable law and risk require it. Customers should report suspected account compromise, unintended repository access or payment anomalies promptly to adam@sprow.co with non-secret reproduction details.
For responsible vulnerability disclosure, include the affected URL, impact and safe reproduction steps. Do not access another user's data, degrade the service or disclose a vulnerability publicly before we have had a reasonable opportunity to investigate.
9. Transparency
stackferry does not currently claim ISO 27001, SOC 2, PCI certification or another independent certification. Stripe handles card data within its own compliance programme; that does not make the entire stackferry service PCI certified.
We update this page when material controls or service boundaries change. Security questions for a procurement review can be sent to adam@sprow.co.