SelfSubmit is designed to help you stay compliant with HMRC Making Tax Digital requirements. You remain responsible for ensuring the information you submit is accurate.

Operations

Infrastructure

SelfSubmit runs on managed cloud services — not your own servers. This page maps the usual enterprise checklist to what actually applies and what you should do.

9 of 10 items apply directly. Firewall in the traditional sense does not — managed cloud hosting, a managed database, HTTPS, and authentication replace it. You do not need to buy servers or install iptables.

Your stack

LayerProvider
Application & CDNManaged cloud host
DatabaseManaged PostgreSQL
AuthenticationClerk
PaymentsStripe
EmailResend
SMSSMS provider (optional)

Checklist

Backups

Shared

Database and file data must be recoverable if something goes wrong.

Provider: Our managed PostgreSQL host provides automated backups on paid plans. Receipt and document files are stored in durable cloud object storage.

What to do

  • In your managed database console, confirm backup / point-in-time recovery (PITR) is enabled on your plan.
  • Keep DATABASE_URL and DIRECT_URL only in production environment variables — never in git.
  • Receipt files live in cloud object storage; submissions and records live in the managed database — both are production-critical.

Backup testing

Your action

A backup you have never restored is only a hope. Test at least once before HMRC live filing.

What to do

  • Create a restore branch or export a snapshot to a development database quarterly.
  • Verify you can read submissions, businesses, and receipts metadata after restore.
  • Log the test date (spreadsheet or internal note) — auditors and insurers like evidence.

Disaster recovery (DR) plan

Your action

A short written plan is enough at your scale — you are not running a secondary datacentre.

What to do

  • Document: if the cloud host is down → check the provider status page, post on /status, wait for the provider.
  • If the managed database is down → check that provider’s status page; restore from PITR or a failover branch per their docs.
  • If Clerk is down → sign-in blocked; communicate via email/status page; no local workaround.
  • Owner contact: support@selfsubmit.co.uk. Target: restore service within 24 hours for major outages.

Monitoring

Shared

Know when the app or cron jobs fail before users tell you.

Provider: The cloud host shows deployment errors, function failures, and cron run history.

What to do

  • Review host logs and observability after each production deploy.
  • Keep error-monitoring DSN environment variables set in production for stack-trace alerts.
  • Optional: UptimeRobot or similar (free) ping https://www.selfsubmit.co.uk and /api/cron/… health if you add one.
  • Watch Stripe, Clerk, and Resend dashboards for webhook delivery failures.

Logs

Shared

Runtime and audit trails for debugging and security.

Provider: The cloud host retains function and edge logs. Clerk and Stripe log webhooks and auth events in their dashboards.

What to do

  • Use the host’s log viewer when investigating 500 errors or failed cron runs.
  • Login attempts and security notifications are stored in the managed database (Settings → Login protection).
  • Do not log UTR, NI numbers, or passwords in application code.
  • Optional: forward host logs to a log service if you need long retention.

Uptime

Shared

Availability expectations for customers and HMRC sandbox credibility.

Provider: A global edge network hosts the app; typical SLA depends on your cloud hosting plan.

What to do

  • Publish service health on /status (already on the site).
  • Subscribe to your cloud host and database provider status pages for incidents.
  • Optional: external uptime monitor emailing you when the homepage is unreachable.

DB monitoring

Shared

Database health, connections, and storage.

Provider: The managed database console shows CPU, connections, storage, and query insights.

What to do

  • Set email alerts for storage limits and connection spikes in the database console.
  • Use pooled DATABASE_URL in production (…-pooler… host) as already configured.
  • Run prisma migrate deploy in CI/build (already in the production build command).

CDN

Provider-managed

Fast static delivery and edge caching worldwide.

Provider: The cloud host automatically serves the Next.js app and static assets from its CDN / edge network. No separate CDN to configure.

What to do

  • Ensure images and icons are served from the app domain (already the case).

DDoS protection

Shared

Mitigate traffic floods and abusive sign-in patterns.

Provider: The cloud host includes platform-level DDoS mitigation. Clerk Attack protection (bot detection) adds sign-up/sign-in abuse filtering.

What to do

  • Keep Clerk bot detection enabled (you already have this).
  • SelfSubmit login-protection lockouts limit brute-force on your APIs.
  • Higher hosting plans may offer additional WAF / IP rules if you ever need them.

Firewall

Provider-managedN/A — different model

Traditional perimeter firewalls apply to servers you own — not this architecture.

Provider: You use serverless functions and a managed database. Security is enforced by HTTPS-only access, Clerk authentication, API route protection, database network isolation, and platform networking — not a hardware firewall you configure.

What to do

  • No action required for a classic firewall.
  • Optional later: a CDN/WAF in front of the domain, or host firewall rules on a higher plan.
  • Keep middleware protecting /dashboard and API routes (already in place).

Recommended next steps (priority order)

  1. Confirm managed database backups / PITR on your plan.
  2. Bookmark host logs and database monitoring; check after each production deploy.
  3. Verify Stripe + Clerk webhooks show successful deliveries in their dashboards.
  4. Once before HMRC live filing: restore the database to a test branch and spot-check data.
  5. Write a one-page DR note (email + status page + provider status URLs) — keep it in your records.
  6. Optional: free uptime monitor on https://www.selfsubmit.co.uk and error-monitoring alerts.