Evaluating CloudSource
Security & data residency
Self-hosting changes the security conversation rather than ending it. This page covers what your review board will ask, and is honest about which answers are ours and which are yours.
The shape of the model
CloudSource ships as source code that you deploy into infrastructure you own. There is no CloudSource-operated service in the path between your editors and your content, and no telemetry destination outside your account.
We are responsible for
- The application source code you receive.
- Publishing fixes and updates to the repository.
- Documenting how the system should be configured.
You are responsible for
- The AWS account, its IAM policies and network configuration.
- TLS certificates, backups and patching the environment.
- Applying updates from the repository on your own schedule.
- Who has admin access, and how they authenticate.
Because the deployment is entirely yours, your existing AWS compliance position carries over. If your account is already in scope for an audit, CloudSource sits inside that scope rather than alongside it.
Where your data lives
All of it, in the AWS region you deploy into. Nothing is replicated elsewhere unless you configure that yourself.
| Data | Stored in | Controlled by |
|---|---|---|
| Content models and entries | Your database instance | Your VPC, security groups and encryption settings |
| Media files | Your S3 bucket | Your bucket policy, ACLs and KMS keys |
| User accounts | Your database instance | You |
| API keys | Your database instance | You, per space |
| Application logs | Your CloudWatch log groups | Your retention policy |
For teams with EU or UK residency requirements, this is usually the deciding factor:
deploy into eu-west-1 or eu-west-2
and the residency question is answered by your own account configuration, with no
vendor data processing agreement needed for the CMS itself.
API access control
The delivery API is read-only and serves published content only. Drafts and scheduled items are never returned.
- Set an API key in Settings and every request must present it.
- Prefer the header form,
Authorization: Bearer YOUR_API_KEY, so keys stay out of logs and referrer headers. - Keys are scoped per space, so a compromised key for one brand does not expose another.
- CORS is enabled, which means a browser client can call the API directly — consider whether you want that, or whether reads should go through your own backend.
The API is open until you configure a key. That default is convenient while you are developing and wrong for production. Setting a key should be on your go-live checklist.
If you use the api_key query parameter instead of the header, assume the key will appear in access logs and browser history. Treat it as lower-trust.
Admin access
Three roles determine what a signed-in user can do. Assign the lowest one that lets someone do their job.
| Role | Can do | Cannot do |
|---|---|---|
| Super Admin | Everything: spaces, users, imports, settings, all content | — |
| Editor | Create, edit and publish content; manage media | Manage users or spaces |
| Author | Create and edit their own content | Publish, or touch other people's work |
There is no per-model or per-field permission system. If your governance model needs that granularity, use separate spaces to create the boundary, or plan to extend the source.
A go-live checklist
None of this is CloudSource-specific, which is rather the point — it is the same checklist you already run for any AWS workload.
- Set an API key and rotate the development one.
- Terminate TLS at CloudFront with a certificate from ACM.
- Restrict the admin panel to your office or VPN ranges if you can.
- Enable encryption at rest on the database and the S3 bucket.
- Turn on automated database backups and test a restore before you need one.
- Give the application an IAM role scoped to its own bucket, not a broad policy.
- Set CloudWatch log retention deliberately rather than leaving it indefinite.
- Decide who holds Super Admin, and keep the list short.
Running a formal vendor security assessment? Get in touch at [email protected] and tell us what your questionnaire needs. Because you receive the source, your team can also review the code directly — something a SaaS vendor cannot offer.