Evaluating CloudSource
Is CloudSource right for you?
CloudSource is a good fit for a specific kind of team, and a bad fit for others. This page is written to help you work out which one you are before you spend anything.
The short version
CloudSource replaces a subscription headless CMS with software you buy once and run yourself. Your editors get an admin panel for modelling content, managing media and publishing. Your storefront reads the result over a JSON API. The whole thing sits inside your AWS account.
The trade is straightforward: you stop paying a platform fee that scales with your catalogue, and you take on responsibility for running the infrastructure.
You are probably a good fit if
- You already run workloads on AWS.
- Someone on your team can own an Elastic Beanstalk environment.
- Your CMS bill grows every time the catalogue, locale count or team does.
- Editors author in a UI; your frontend reads over an API.
- Data residency or procurement makes vendor hosting awkward.
You are probably not, if
- You need a contractual uptime SLA backed by someone else's on-call rota.
- A pipeline writes content programmatically and needs a management API.
- You depend on a marketplace of third-party CMS integrations.
- Your frontend is built around GraphQL and you do not want to change it.
- Nobody wants to own infrastructure, at any price.
What you need in place
None of this is exotic, but it is worth confirming before you buy rather than after.
| Requirement | Why it matters |
|---|---|
| An AWS account you control | Everything deploys into it. If your infrastructure is on another cloud, CloudSource is not the right tool. |
| Someone comfortable in the AWS console | Creating an Elastic Beanstalk environment, an S3 bucket and a CloudFront distribution, and setting environment variables. Not a specialist, but not nobody. |
| A GitHub account | The software is delivered as access to a private repository. You will need somewhere to clone it and, ideally, a fork or mirror of your own. |
| Frontend development capacity | Your storefront needs to read from a new API with a different response shape. This is usually the largest part of a migration. |
| A budget line for AWS | The licence is one-off; the infrastructure is ongoing. See what it costs to run. |
What actually changes on switching day
Three things move, and they move at different speeds.
- Your content moves in an afternoon Export the Contentful space as JSON, upload it in Tools → Import. Models, assets and entries are recreated, with references resolved. The migration guide covers the detail.
- Your editors move in a morning The concepts carry over directly: content types become models, entries stay entries, assets stay assets, and drafts still have to be published. Most teams find this the easy part.
- Your storefront takes a sprint This is the real work. Response shapes differ, so every place your code reads a field needs updating and retesting. Scope this properly — it is the part teams underestimate.
Run both in parallel. Nothing forces a hard cutover. Import your content, point a staging build of your storefront at the new API, and keep the subscription running until you are satisfied. Cancel it at the next renewal date rather than mid-term.
Questions worth asking us
A demo is more useful when you arrive with the awkward questions. These are the ones that most often decide the outcome:
- Here is our content model — how would you build it in CloudSource?
- Here is our peak-day traffic profile — what would you size the environment at?
- We need content to stay in a particular region — what does that constrain?
- We have a workflow that writes entries automatically — is there a path for that?
- What does the priority support add-on cover, and what does it cost?
Bring a Contentful export if you have one. It is the fastest way to find out whether your model maps cleanly.