Home
Blog
Showcase
Community
Introduction
Overview
Introduction To TinaCMS
Getting Started
Using the Tina Editor
FAQ
Core Concepts
Content Modeling
Data Fetching
Visual Editing
Querying Content
Overview
Writing custom queries
Editing
Overview
Markdown & MDX
Block-based editing
Single Document Collections
Customizing Tina
Overview
Validation
Custom Field Components
Custom List Rendering
Format and Parse Input
Filename Customization
Before Submit function
Going To Production
Overview
Tina Cloud
Overview
The Dashboard
Deployment Options
API Versioning
Self-Hosted
Drafts
Overview
Draft Fields
Editorial Workflow
Guides
Overview
Framework Guides
Separate Content Repo
Querying Tina Content at Runtime
Internationalization
Migrating From Forestry
Further Reference
Overview
Config
Schema
The "tina" folder
The TinaCMS CLI
Media
Search
Content API
Tina's edit state
The "tinaField" helper
Self-Hosted Components

Going to Production with TinaCloud


To deploy your site to production, you'll need to connect Tina to a hosted backend. This doc will walk you through the steps to get your site from running locally to running for production.

Prerequisites

  • Make sure your site is on Github and all changes are pushed (including tina/tina-lock.json).
  • Make sure you have a TinaCloud account.

Make a TinaCloud Project

Go to app.tina.io and create a new project. You'll be asked to connect your Github account and select the repository you want to connect to TinaCloud.

Run the Backend Init Command

The next step is to connect your site. Once connected, your project's editors will be able to save content directly to its GitHub repository, entirely from within your site.

npx @tinacms/cli init backend

This will

  • Ask you for your ClientId: Can be found in the "Overview" tab of your project.
  • Ask you for a Read Only Token: Can be found in the "Tokens" tab of your project.
  • Populate your .env file with the necessary environment variables to connect to TinaCloud.
    • If you are using a different environment variable file, OR you have an existing .env fileyou will need to copy these variables over manually.

Ensure ClientId and Token are Passed to the Config

In the your tina/config file, make sure the clientId and token are passed to the config.

// tina/config.ts
//...
export default defineConfig({
//...
token: process.env.TINA_TOKEN, // This should match the value in your .env file
clientId: process.env.NEXT_PUBLIC_TINA_CLIENT_ID // This should match the value in your .env file
branch,
schema: {
collections: [
//...
// See https://tina.io/docs/schema/ for more info about "collections"
]}
})

Note: If you're loading your schema config values from a local environment file, Tina's build process will only pickup .env files (not .env.local or .env.development)

Configuring the branch

This is may have already been setup in the init process but you should ensure that the branch is being passed to the config.

Typically you'll want to use the branch that you're deploying with your site. This will vary depending on your host, but most will provide an environment variable of some sort that you can use.

// tina/config.ts
//...
+ const branch =
+ process.env.NEXT_PUBLIC_TINA_BRANCH ||
+ process.env.NEXT_PUBLIC_VERCEL_GIT_COMMIT_REF ||
+ process.env.HEAD ||
+ ''
export default defineConfig({
//...
token: '<Your Read Only Token>' // generated on app.tina.io,
clientId: '<Your Client ID>', // generated on app.tina.io
branch,
schema: {
collections: [
//...
// See https://tina.io/docs/schema/ for more info about "collections"
]}
})
NEXT_PUBLIC_VERCEL_GIT_COMMIT_REF is Vercel's system environment variable that represents the branch that has made the deployment commit. HEAD is the equivalent system environment variable used by Netlify.

Your fully configured tina/config.{js,ts} should look something like this:

import { defineConfig } from 'tinacms'
const branch =
process.env.NEXT_PUBLIC_TINA_BRANCH ||
process.env.NEXT_PUBLIC_VERCEL_GIT_COMMIT_REF ||
process.env.HEAD
export default defineConfig({
token: '<Your Read Only Token>' // generated on app.tina.io
clientId: '<Your Client ID>', // generated on app.tina.io
branch,
schema: {
// ...
},
})

The apiURL is configured to use the local Content API in development (to query your local files), and the hosted content API (with auth) in production.

Deploying your site (with the TinaCMS admin)

The next step is to update your deployment configuration, so the TinaCMS admin gets built alongside your site. This allows your editors to enter the CMS through <your-site>/admin (or your-site/admin/index.html).

In general, you'll want to make sure that your build command is running tinacms build before your site's build command. This will build the TinaCMS admin alongside your site. You'll also want to make sure that your Tina NEXT_PUBLIC_TINA_CLIENT_ID and TINA_TOKEN are setup as environment variables on your host.

We have docs for some popular deployment options:

Previous
Going to Production
Next
TinaCloud Dashboard

Product

Showcase
TinaCloud
Introduction
How Tina Works
Roadmap

Resources

Blog
Examples
Support
Media

Whats New
TinaCMS
TinaCloud
Use Cases
Agencies
Documentation
Teams
Jamstack CMS
Benefits
MDX
Markdown
Git
Editorial Workflow
Customization
SEO
Comparisons
TinaCMS vs Storyblok
TinaCMS vs Sanity
TinaCMS vs DecapCMS
TinaCMS vs Contentful
TinaCMS vs Builder.io
TinaCMS vs Strapi
Integrations
Astro
Hugo
NextJS
Jekyll