FAQ

TinaCloud is a hosted datalayer for TinaCMS. TinaCloud is the easiest way to use TinaCMS in production. It provides:

• A hosted GraphQL endpoint for your content
• Git integration
• User management
• Editorial Workflow features

It also allows authorization for different types of users (content creators, editors, marketers, etc) to login and edit their site without needing to grant direct access to the repository in GitHub.

TinaCMS can be self-hosted or used independently of TinaCloud as well.

For more information, see TinaCloud Overview.

Check out our communities at tina.io/community.

Anyone can start using TinaCMS right away but it is designed for developers to setup and customize. A certified developer can accelerate the setup, fine-tune the configuration, and ensure best-practice architecture.

TinaCMS is supported on all active LTS versions of Node. See Node.js Releases to find out more about release versions.

NPM, PNPM, Yarn and Bun package managers are all supported. We recommend PNPM, which is the default in create-tina-app and the package manager we use to develop TinaCMS.

Table updated May 2026

TinaCloud

• Content querying + indexing - Node
• Cloud provider - AWS
• Identity management - Go

TinaCMS

• CMS - React 18 / React 19

When comparing TinaCloud with self-hosting TinaCMS, there are specific features unique to TinaCloud. These include:

1. Git Backed Media

In TinaCloud, there's a Git backed media feature. This integrates media into the TinaCMS Media Manager and commits it directly to the Git repository. However, this functionality is not present in self-hosted TinaCMS.

The reason for its absence is due to the process involving media uploads. When using the media manager in TinaCloud, images are uploaded to TinaCloud servers and distributed via a CDN. This ensures that images are accessible through the TinaCMS Media Manager, as they require a URL for accessibility. Without this, images won't appear in the Media Manager until the site is rebuilt.

2. Dynamic Branch Switching at Runtime

TinaCloud allows for changing the content branch at runtime, a feature managed through URL modification. However, in self-hosted TinaCMS, changing branches is restricted to the build phase only.

This limitation means that commands like...

...are not functional in a self-hosted TinaCMS setup.

3. Search

The self-hosted backend does not currently have endpoints to support search functionality.

By default when using TinaCloud, the author on Git commits is the TinaCloud GitHub app. Some users prefer to know who made the change.

For this use case, TinaCMS allows two different methods:

1. GitHub authoring in order to attribute actions to a GitHub account.
2. Co-author Git commits in order to attribute the commit to an additional user.

Both of these can be enabled per-user in the TinaCloud account settings. Find out more about Git Authoring.

A database is essential when using markdown with TinaCMS because the Data Layer, which serves Markdown and JSON files, relies on a database to perform various content management functions. While the Markdown files are the primary source of your content, the database acts as a cache to enable advanced features like search, pagination, and cross-referencing between files. It also provides an API, allowing content fetching akin to traditional headless CMS operations.

Initially, TinaCMS's Data Layer operates unnoticed during local development and is managed by TinaCloud in production. With the introduction of self-hosted options, users can now opt for more control and customization, integrating their own authentication systems and hosting. The entire TinaCMS, including its Data Layer, is open-source, allowing for community-driven enhancements and support.

Local Mode

When developers are developing locally, it's often convenient to load/save content from their local filesystem rather than connecting to the content on TinaCloud.

When in local-mode, you will not need to login to enter edit-mode.

Note: Local-mode is meant for developing locally, and will not work when your site is hosted on production. When in local-mode, TinaCMS tries to hit http://localhost:4001, which isn't available at runtime on your production site (and neither is the underlying filesystem content).

Prod Mode

Once you are ready to host your site in production and put editing behind authentication, you can self-host the CMS backend yourself or you can use TinaCloud's hosted backend.

Whether you're self-hosting TinaCMS or using TinaCloud, TinaCMS's Content API authenticates directly with GitHub removing the need for users to create GitHub accounts. Any changes that are saved by your editors will be committed to the configured branch in your GitHub repository.

Currently yes, the first Git provider that TinaCloud integrates with is GitHub. Other Git providers may be available in the future.

It does! TinaCloud can work with sites inside monorepos by specifying the path to your tina folder in your project configuration.

If your repo is not a monorepo, there's no need to do any configuration. We'll expect your tina folder at the root of your repo.

Here's an example monorepo structure that works with TinaCloud:

See Path To TinaCMS for more information.

When a user logs in from your site, we will pop open a login window. When login is complete, we will attempt to send a message back to the main window.

The most common reasons for this issue are:

• The Site URL is not properly set for the TinaCMS project. The main window's base URL will need to match the TinaCMS project's Site URL setup in the TinaCloud Dashboard.
• The Client ID setup in your site's environment variables does not match the Client ID in your project's settings on the TinaCloud dashboard.
• The user attempting to login to TinaCloud does not have access to edit this site. Ensure that this user is authorized on the TinaCloud dashboard.

Make sure to include https in the Site URL eg: https://example.com or if you are testing locally, it might be something like http://localhost:3000

Site is building on a sub-path

There is a known limitation where TinaCMS doesn't load assets correctly when the admin is deployed to a sub-path: (https://jamespohalloran.github.io/my-site-root/admin/ for example). To resolve the issue, in your TinaCMS config file, set the build.basePath property to value of the sub-path (e.g. my-site-root).

This error means that the TinaCMS admin HTML file failed to load the JavaScript bundle. This generally happens for a few reasons:

User has pushed the development admin/index.html to production

When you run tinacms dev locally, TinaCMS will generate a development admin/index.html file, which loads its assets from localhost. For production, this file should be built in CI using tinacms build. If a developer manually removes the admin/index.html file from their .gitignore, they may run into this issue.

Your site is served on a different base path

If your site is served at a sub-directory, ensure that your build.basePath is configured appropriately

See the TinaCloud troubleshooting page for more information.

In production

Make sure your API URL isn't set to point at your local GraphQL server when in production. You should be pointing to the ContentAPI.

Locally

If you are working locally, make sure your GraphQL server is running.

1. Popup blocker prevents Vercel from installing their GitHub app

After choosing which starter template to deploy and being redirected to Vercel, a popup for Vercel to add their GitHub app may fail to open. Look in the bottom left corner for a toast message saying "The popup to install the GitHub App could not be opened."

Figure: Popup blocked

To fix, check your browser's address bar for blocked popups, allow them, and retry.

Yes. TinaCMS is designed to be highly LLM-friendly, mainly because it uses Markdown for structuring content.

Markdown gives Large Language Models (LLMs) clear advantages:

• Clear structure – headings, lists, and code blocks are easier to parse
• Semantic meaning – formatting adds clarity and context
• Prompt-friendly – consistent markup reduces ambiguity
• Readable for humans & machines – raw Markdown works well for both
• Aligned with LLM trends – Markdown fits naturally with the shift toward LLM-optimized content, as highlighted in SEO is Dead, Long Live LLMO

Unfortunately we do not support Git LFS at this time due to limitations with the GitHub API.

When using the reference field on a collection with a large number of items, you may find the network requests time out. Currently, we do not have anything in place to paginate the reference field.

The alternative would be to add a custom field component with pagination. To retrieve the paginated results, you can use a custom query.

No! Only the individual who sets up the TinaCloud project, linking it to a GitHub repository, requires GitHub.

Editors can create a TinaCloud account with just their email. If co-authoring is enabled for the editor, then commits will be co-authored by their email address.

Due to a current limitation in GitHub Copilot’s webhook behaviour, branches created through GitHub Copilot assignments are not automatically indexed by TinaCloud. These branches do not trigger the branch creation webhook that TinaCloud relies on to begin indexing content.

We have raised this issue with GitHub and will provide updates as they become available in this Issue.

As a temporary workaround, branches created by GitHub Copilot can be manually re-indexed from the TinaCloud dashboard.

Figure: Re-indexing GitHub Copilot branches in Tinacloud

Renaming media files is not currently supported through the TinaCloud Media Manager. Repo-based media only tracks a single branch and does not have branching functionality for media operations like renaming. If the tracked branch is protected, uploading a renamed file will save it to storage (S3) but the change will not be committed to the branch.

As a workaround, you can rename media files by making the changes directly in GitHub:

1. Delete the old file from your media directory (e.g. public/uploads/) directly in GitHub
2. Wait for the deletion to sync back to TinaCloud
3. Add the file with the new name directly in GitHub
4. Wait for the addition to sync back to TinaCloud

For more details, see Renaming Media Files.

This happens under npm when two major versions of Vite end up in the dependency tree — for example, Vite 8 pulled in by @tailwindcss/vite alongside the Vite 7 that Astro uses. The mismatched rolldown bindings crash the build.

We recommend pnpm, which resolves to a single Vite version automatically and avoids this class of issue. If you must use npm, delete node_modules and package-lock.json, reinstall, and pin Vite with an overrides block in package.json: