Cloud Native

Messagevisor is agnostic of what Git host, CI/CD tool, or storage you use. It generates static JSON datafiles that can be served from any CDN, any object store, or bundled directly into your application, making it a cloud native solution you can shape to your infrastructure.

What is cloud native?#

Cloud native describes a way of building and running software that fully embraces the properties of modern cloud infrastructure: elastic compute, managed services, edge delivery, and a separation between the things that change often (configuration, content) and the things that change rarely (the runtime that serves them).

A cloud native system tends to be:

Scalable: scales horizontally without coordination, because state lives in shared, replicated storage.
Flexible: does not assume a specific vendor or platform; pieces can be swapped without rewriting the system.
Resilient: failures of individual components do not bring the whole system down.
Fast to update: new versions ship through an automated pipeline, not a manual deploy.

Cloud native in Messagevisor#

Messagevisor is built around two cloud native ideas:

Definitions in Git, datafiles as build artifacts. The source of truth is a Git repository. The runtime payload is a set of static JSON files produced by a build step.
Unopinionated infrastructure. Messagevisor does not run a server, does not require a database, and does not depend on a specific cloud provider. You bring the Git host, the CI, and the place where datafiles live.

In its simplest form, all Messagevisor requires is:

a Git repository for the project
a CI/CD job that runs messagevisor lint, messagevisor test, and messagevisor build
a place to publish the generated datafiles/ directory (a CDN, an object store, or the application bundle itself)

That is the whole platform.

How it works#

Declarative configuration#

Locales, messages, segments, attributes, and targets are authored as YAML or JSON files with a documented schema. You describe what should be true, not how to make it true.

See Messages, Locales, Segments, and Targets.

GitOps workflow#

All changes flow through pull requests. CI validates them. On merge, CI builds and publishes datafiles. See GitOps for the full picture.

Static JSON datafiles#

The build step compiles definitions into one datafile per target and locale. Datafiles are plain JSON:

they can be cached aggressively
they can be served from any HTTP origin
they have no runtime dependency on Messagevisor's own infrastructure
they update independently of application deploys

The SDK fetches them, or your build pipeline bundles them. Either way, there is no Messagevisor backend in the request path.

Unopinionated infrastructure#

Messagevisor does not assume a Git host: GitHub, GitLab, Bitbucket, or self-hosted Git all work.

It does not assume a CI: GitHub Actions, GitLab CI, CircleCI, Jenkins, Buildkite, and others are equally supported.

It does not assume a place to publish datafiles: AWS S3 + CloudFront, Cloudflare Workers + KV or Static Assets, Google Cloud Storage, Azure Blob Storage, Vercel, Netlify, or your own origin all work.

See the existing deployment guides for concrete recipes:

The list is not exhaustive. Anywhere that can serve a directory of JSON files over HTTPS is a valid target.

A minimal cloud native pipeline#

.github/workflows/deploy.yml

- run: npx messagevisor lint
- run: npx messagevisor test
- run: npx messagevisor build
- run: aws s3 sync datafiles/ s3://my-cdn-bucket/messagevisor/

That is enough to run a production Messagevisor deployment. No control plane, no managed service, no extra credentials.

What this means for you#

No vendor lock-in. The project is plain files in your repository and plain JSON on your CDN. You can switch hosts, CIs, or storage backends without changing your authoring model.
Free choice of runtime. Use the JavaScript SDK in Node.js, the browser, Cloudflare Workers, Deno, Bun, edge runtimes, or anywhere else a JavaScript runtime fits. Datafiles are just JSON, so non-JS runtimes can consume them too.
No Messagevisor server in the request path. Reads at runtime hit your CDN. Latency, availability, and cost are properties of your infrastructure, not ours.
Cheap at any scale. Static JSON over a CDN is one of the cheapest workloads in the cloud. The cost of running Messagevisor in production is the cost of the CDN traffic plus the CI minutes for builds.
Transparency. Every change is a pull request, every build is a CI run, every deploy is a published artifact you can inspect.

Comparison with hosted alternatives#

Most translation management products are SaaS platforms: you author content in their UI, they store it in their database, your application fetches it from their API at runtime. That model trades infrastructure ownership for convenience.

Messagevisor goes the other way:

Concern	Hosted TMS	Messagevisor
Source of truth	Vendor database	Your Git repository
Runtime path	Vendor API	Your CDN
Vendor lock-in	High. Content lives in their schema and API.	None. Content is YAML in your repo, runtime is JSON over HTTP.
Cost shape	Per-seat / per-MAU pricing	CDN traffic + CI minutes
Review and CI	Vendor-specific, often limited	Standard pull request review with CI
Offline / air-gapped	Difficult	Bundle datafiles with the app

If a hosted UI for non-technical translators is the primary requirement, a SaaS TMS may be the right fit. If you want translation behavior to be part of your product's engineering system, cloud native is the better trade.

Conclusion#

Cloud native is not a marketing label, it is a set of properties that fall out of treating content as data and infrastructure as a choice. Messagevisor embraces those properties: a Git-based source of truth, static JSON build artifacts, and no opinions about where you run your CI or host your CDN.

You bring the infrastructure you already trust. Messagevisor handles the authoring, validation, build, and runtime resolution.