Security: how we deploy and run your software
We don't hand over a zip file. We deploy the software we build and keep it running on infrastructure we manage, so this page sets out exactly how we do that, including what we don't have.
Book a free 30-min intro call
Building it is half the job
Most of what goes wrong with business software goes wrong after launch: a leaked credential, a database nobody backed up, a change that reached production untested. So for most clients we run what we build. Everything below is how our own platform works today, written down from the infrastructure code, not from a policy template.
Hosting and where your data lives
- Applications run on Google Cloud, on Google Kubernetes Engine, in the europe-west1 region (Belgium) by default. Another region can be set up for your project; ask on the intro call.
- Databases are managed PostgreSQL on Cloud SQL, with automated daily backups kept for seven days.
- Staging and production are separate environments. Every change runs on staging before it can reach production.
- Your team signs in with the accounts it already has, such as Microsoft or Google, and access inside the application is by role.
Secrets
- Credentials live in HashiCorp Vault inside the cluster, unsealed with Google Cloud KMS, and in Google Secret Manager. They are mounted into the application at runtime, never written into code, config files or the repository.
- Services authenticate to Google Cloud with Workload Identity, so there are no long-lived service-account key files to leak or rotate.
- Internal tokens are generated and stored straight into Secret Manager, without the value ever being displayed to the person creating it.
Network access
- Cluster nodes are private: they have no public IP addresses.
- Public services sit behind Google's load balancer, with Cloud Armor edge rules that block abusive crawler and bot networks before they reach the application.
- Admin tools and database access are reachable only from inside our private Tailscale network, never from the public internet. The network policy itself is kept in a repository and applied by CI, not edited by hand.
How a change reaches production
- All infrastructure is code (Terraform), changed through reviewed pull requests, so every setting is versioned and the history says who changed what and when.
- Every pull request across our repositories runs linting with security rules (gosec), Go vulnerability scanning (govulncheck), and an automated security review that blocks the merge when it finds a concern.
- Dependabot watches dependencies, and a scheduled scan re-checks the main branch of every live repository, filing anything it finds as an issue.
- A release promotes to production the exact image that already ran on staging, and automated end-to-end tests run against staging every day.
Monitoring
- Google Cloud Monitoring alert policies, defined in the same infrastructure code, watch production databases for CPU, memory and disk pressure, and for runaway disk growth, and notify us by email.
- Application errors and product events are tracked, so a failure shows up with its context rather than as a customer email.
Your code, and your way out
- You own the source code, the infrastructure configuration and the documentation, and that is written into the contract.
- Because the infrastructure is code, the whole platform can be redeployed into your own cloud account, or handed to your team or another firm, without reverse-engineering anything.
What we don't claim
A security page that only lists strengths is a sales page. These are the things a procurement team would ask about that we don't have today.
- We are not SOC 2 or ISO 27001 certified. We answer your security questionnaire item by item, with evidence from the systems themselves.
- Database backups are daily snapshots kept for seven days, not point-in-time recovery. If your project needs a tighter recovery point, we configure it for that project.
- Our private network keeps admin access off the public internet, but it does not yet restrict each person to individual services.
Frequently asked questions
Where is our data hosted?
By default on Google Cloud in the europe-west1 region, in Belgium, inside the EU. Databases are managed PostgreSQL on Cloud SQL. If your project needs another region, we set it up for that project; tell us the constraint on the intro call.
Are you SOC 2 certified?
No, and neither are we ISO 27001 certified. We answer your security questionnaire point by point with evidence from the actual systems: how access is granted, where data is stored, how secrets are handled, how changes are reviewed and deployed. If your procurement requires a SOC 2 report from every vendor, tell us early and we will say honestly whether we fit.
How are passwords and API keys handled?
They live in HashiCorp Vault and Google Secret Manager and are mounted into the application at runtime. They are never in the code, in config files or in the repository, and services reach Google Cloud through Workload Identity rather than key files.
Can you deploy into our own cloud account?
Yes. The infrastructure is written as Terraform, so the same platform can be deployed into a Google Cloud project you own, with your own billing and access controls. We can then run it for you there, or hand it over to your team.
What happens when something breaks in production?
Alert policies on production databases notify us by email when CPU, memory or disk run high, and application errors are tracked with their context. Because every release is the image that already ran on staging, rolling back means redeploying the previous image.
Who owns the code and the infrastructure?
You do, including the source code, the infrastructure configuration and the documentation, and it is written into the contract. If you later move the project in-house or to another firm, the infrastructure code means nothing has to be rebuilt from scratch.
Bring us your security questionnaire
A free 30-minute call. Send the questionnaire first if you have one and we will walk through our answers, including the ones where we don't fit.
