Self-hosted alternative to Tina Cloud

[scottgallant]

[UPDATE] You can now self-host Tina! See the docs or check out this 2-minute video that shows how to self-host on Vercel: https://www.youtube.com/watch?v=DAJpnjkLBbM

Add your vote for a self-hosted alternative to Tina Cloud by clicking the 👍 and ⬆ below.

If you can describe your use case in the comments below, that will help inform us on how this should work and its priority.

See the self-hosted docs for more background on our vision.

[danielknell]

Even when there is the best of intentions, companies and products come and go, good companies can go bankrupt, or be acquired by other larger companies who eventually sunset the existing products.

And sometimes clients/employers are just a complete pain in the arse, and refuse to budge on draconian polices against third party access to git repos.

Storing everything in git solves some of those problems, the content is there, co-located with the code that renders it, no external factor can hinder that, if the hosting goes down it can be quickly redeployed elsewhere, but on the editing side, its only protected assuming the writers/editors are also technically savvy and can understand both markdown and git, and lets face it, git is an abomination of a tool UX wise, which many skilled developers struggle with...

Having to move things to a new CMS, especially given the deep integration you would have with TinaCMS using a react based SSG would be a sizeable undertaking, and during that time updates to the site would be problematic.

An open source alternative to the cloud offering makes it a lot easier to buy into the ecosystem, as the external piece is a convenience rather than necessity, lets face it, we are statically generating because we want to avoid the hassle of running a server, but in the worst case scenario, everything can be in-housed.

It also opens the possibility of maintaining a fork should there be some niche functionality that is lacking in the cloud offering, maybe this could be made easier with sensible extension points (e.g. make it easy to add new graphql resources without a fork, some kind of plugins? which in turn could help guide feature development on the cloud offering...).

[scottgallant]

Right. We want Tina Cloud to be opt-in, not lock-in.

make it easy to add new graphql resources

I'm not following you there. Can you elaborate on what you were thinking?

[danielknell]

the cloud part is simplistically the business logic of which content to return sandwiched between a graphql endpoint at the top, and a content store (local filesystem or GitHub) at the bottom.

if that middle layer was composable via plugins, then it would allow the self hosted system to be an easy testbed for unstable functionality, and for the community to build its own functionality which in turn could find its way back into the main offering.

Example:

One of my sites has tags, to build a tag page / tag cloud I currently have to pull every item in the entire collection, and iterate over it client side to find the unique tags and their counts...

I could build a query resolver that did that within the self hosted offering, this could be built out and tested independently, the interface refined and polished, etc, etc, without the tina dev team needing to be involved.

if this hypothetical plugin took off and loads of folk are interested in it, then that's a good indication something similar would be a good addition to the cloud offering, if like 3 end up using it, then the functionality is there if folk really need it, but they just gotta run it themselves, and it would not be worth the time/effort of maintaining it in the cloud offering.

[joostdecock]

I've already +1'd this excellent summary by @danielknell but I feel perhaps it's worth underscoring how -- from a business point of view -- having a self-hosted option would drive adoption.

I am currently considering my options for a rewrite of the FreeSewing. It's going to be NextJS, and we have a bunch of MDX for docs, blog posts and so on. And while I am happy enough to work with MDX in git, for many of our contributors who come from a sewing background, this is a steep learning curve. So we've tried a few alternatives and currently we use Strapi for some of our content.

However, it's not without its flaws, self-hosting comes with it's own burden that we don't really want, and at the latest contributor call we decided we would look into alternatives and worst case scenario just fall back on git.

On the surface, Tina Cloud would be a perfect fit. But putting all of our eggs in that basket seems risky because:

• It's in beta. Will it stay around?
• When it comes out of beta, how much money will they charge? There is no pricing info and as a poor open source project, this money would come right out of my pocket. There's no corporate backer
• @scottgallant 's answer above (We want Tina Cloud to be opt-in, not lock-in) is nice to read, but words are just that.

So right now, putting the time/effort in to migrate to Tina would be a rather big leap of faith.
Having a view on pricing, or even whether there would be discounts for non-profit/open source could go a long way in addressing that uncertainty.
But at the end of the day, nothing brings peace of mind like knowing that you can always self-host.

[aptfx]

Also a +1 from me. Now/Vercel was once a solution really affordable for devs with smaller needs and really easy to use. Then they introduced their new pricing which started at 20$ per month. For quite a few devs this might be a good price level - but for devs like me its not. I can rent a virtual server for 5 bucks and for small projects this is absolutely enough - particularly for mostly static content which is easily cacheable.

Many vendors offer free tiers which cater for those small needs - a realistic small free tier is really good and would help in putting faith into a platform. Now/Vercel did butcher this free tier too, by making explicit that it is forbidden to get used in any (even remotely) commercial way.

The outcome? I completely ditched Now/Vercel and tell anyone to keep their business away from them. They had multiple strategic changes with big costs and consequences for their customers. They are not a reliable partner in my experience. Small devs are ignored and big devs need to have a LOT of trust in them that they don't again throw them under the bus on their next strategic change.

[inwardmovement]

Can't TinaCMS be just like NetlifyCMS: a client-side React app without the need of a server?

[inwardmovement]

Thanks for the clarification.

Could a kind of serverless functions adapter (Next API routes) be provided, to avoid setting up a server?

[jeffsee55]

Could a kind of serverless functions adapter

Definitely! The hope would be to just allow you to drop in the "graphql" function and you're good to go. But there's a bit of complexity there with the data store and managing various versions while editing. Aside from those kinds of problems, I'd love for it to be something like this:

// pages/api/tina.ts
import { graphql } from '@tinacms/graphql' // or possibly just tinacms/graphql
import db from '../../.tina/__generated__/db

export default function handler(req, res) {
  res.status(200).json(graphql(req.body, db))
}

And then, yes as @danielknell mentioned, open up that graphql function to extension.

[filipesmedeiros]

@jeffsee55

Since TinaCMS serves content as a headless CMS, a server is necessary. We can't rely solely on the Github API as a data source.

Just to clarify, this is only because of authentication, right? Because it is indeed possible to use Tina while having all content live inside the repo? The Tina backend is serving only as a proxy to GH in that case, correct?

[jeffsee55]

@filipesmedeiros not exactly. Tina serves data sourced from Github, but in order to serve it in a performant manner we added an indexing layer that lives on Tina Cloud (the same layer runs on the server locally when you use Tina on your machine).

So yes, part of the self-hosting story will be authentication, but ultimately there's more to be done than just a simple proxy to Github, and we'd like to make sure we can slice up the responsibilities for self-hosting in a way that makes sense. For example, it might still make sense to use Tina Cloud for auth while storing the data on your host. Or it might make sense to use Tina Cloud for all of your data while in edit mode so we can handle versioning through multiple Git branches. We're not exactly sure yet, so we're sticking with Tina Cloud as the only real path to get things working for now.

The more info about your ideal use-case, the better!

[ammarfaris]

@filipesmedeiros not exactly. Tina serves data sourced from Github, but in order to serve it in a performant manner we added an indexing layer that lives on Tina Cloud (the same layer runs on the server locally when you use Tina on your machine).

So yes, part of the self-hosting story will be authentication, but ultimately there's more to be done than just a simple proxy to Github, and we'd like to make sure we can slice up the responsibilities for self-hosting in a way that makes sense. For example, it might still make sense to use Tina Cloud for auth while storing the data on your host. Or it might make sense to use Tina Cloud for all of your data while in edit mode so we can handle versioning through multiple Git branches. We're not exactly sure yet, so we're sticking with Tina Cloud as the only real path to get things working for now.

The more info about your ideal use-case, the better!

Just curious, is the "indexing layer / process" heavy on resources (RAM, CPU)? because we would like to think from the potential of "paid-plans" in the future for Tina Cloud, if there is any, and how much will it potentially cost?

Is there any CDN involved especially for images if opt for Repo-Based Media, or is that handled by the front-end hosts like vercel / netlify?

Thank you!

[knsakib]

Tina with firebase (backed by firebase and cloud storage)

[dasmeet]

Even though I love Firebase, my worry is that it would still be a kind of lock-in.

[Aeolun]

Is there something that Tina Cloud currently does that makes it exceptional? As far as I understand it it's a back-end that basically does git synchronization. If we can replicate that on-premise, without having to go through the internet, then that's a boon for anyone aiming to use this in their VPN (for internal documentation etc).

For myself, I just like to self-host things, there's no real logic to it, I'll just keep searching for a service until I find something that allows me to.

[Aeolun]

Another thing that occurs to me is latency. I'm not sure where Tina Cloud is hosted, but I'm inclined to believe that there may be a fair bit of latency involved in querying the data. Having the data next to the UI would mitigate that problem.

Of course, it's possible it's already globally distributed, and the latency will always be only milliseconds.

[jeffsee55]

As far as I understand it it's a back-end that basically does git synchronization

See the comment above for what Tina Cloud does #3096 (reply in thread)

That being said, we do ship this same logic to the @tinacms/cli to allow you to run it all locally, so it's not much of a leap to make it easy to host on a server somewhere. As mentioned previously, this is trivial for read-operations but for writing and getting that data back over to Github, and for synchronizing async pushes to your repository and for managing various edit states with branches things get a bit more difficult.

I'm inclined to believe that there may be a fair bit of latency involved in querying the data

We're in a similar position as any other headless CMS in this regard, your backend needs to hit another backend. And while some of these other CMSs offer their APIs over a CDN, we aren't there yet. Having said that, we 100% agree with you that self-hosting is a solid solution for potential latency issues.

The other thing about data for a CMS is that it's extremely cache-friendly, and it's one of the reasons most users of Tina are using things like getStaticProps happily. Even without a static build mechanism though, this data should be cached aggressively for your users.

[Aeolun]

The other thing about data for a CMS is that it's extremely cache-friendly

That's a very good point that I hadn't thought of. As long as the queries are cached they can come from anywhere, and that's much easier to distribute (or at least easier to outsource with something like CloudFront).

I think I'll have my own look at whether @tinacms/cli would work for my purposes. If you don't need collaboration then there's probably a way to make it work (I guess you can stick it in a docker container that runs the server, and syncs the repository to/from the VCS every so often).

[jeffsee55]

@Aeolun yes, caching will help a ton. We do expect to be able to deliver world-class performance regardless, but it may take some time before that's realistic.

Regarding running the cli in a container, you can see how things are working here but this comes with a very large USE AT YOUR OWN RISK warning. You'll see we have a few underlying libraries that allow us to index files into a data store. These APIs are highly likely to change and aren't documented at the moment.

[genox]

As a "my five cents": I stumbled over tinacms while searching for a headless CMS solution that is a) open source and b) doesn't require setting up file serving containers, backends, etc - to keep overhead down in small projects. The things that got me hooked is contextual editing and having the data stored in a place where I have complete control.

While talking to my colleagues, some concerns have been raised, especially

• dependency on GitHub, especially the access permissions and why they are needed should be documented somehow. And using GitLab instead of GitHub was a topic, as we generally try to keep things in our control and not depend entirely on a third party SaaS.
• no option to self-host was a turn off for some (performance, security concerns, reliability, long term future, .. etc.)

For me personally, if TinaCloud is fast and the pricing of the service remains on a level that makes it comparable to a shared hosting solution (I am specifically not talking enterprise solutions, tinacms is a really good fit for small projects, especially to keep infrastructure overhead to a minimum), I don't see a super large need to run it myself.

However, lots of organisations (from my experience) want to keep things tight and running one container as a bridge of sorts, especially if it is a multi-tenant solution, would probably be very advantageous.

Honestly I can see a place for tinacms as a SaaS solution for those that don't want to care about backend infrastructure and a self-hosted solution for those that want more control. I like to have options. And it makes it a lot more transparent.

Wether this is a great way to monetise your solution will have to be seen, but that depends on your strategic goals. Personally, I think "open" is always better, but if the service is economically sane and it solves my problem, I am also willing to pay if the framework of the project allows an external solution.

[jonlambert]

They've announced a pricing tier of $28/month/project. This comes into force ~1 week from announcement: 7th November 2022.

[markjaquith]

I want a solution with the minimum number of hard dependencies. GitHub is a hard dependency. But there doesn't need to be another. If the connector functionality could be built as an edge function with connectors for various providers (Cloudflare, Vercel, Fastly, etc), then this dependency would be flexible and I'd have more confidence in Tina as a long-term solution.

[jonlambert]

Just received the following from the TinaCMS team:

The price increase is shocking and the lead time entirely unworkable. Budgets simply do not work like that. I cannot in all good conscience convince a business to spend this sort of money at such short notice.

[aptfx]

Sadly it feels exactly like the Now/Vercel disaster I had. I‘m a professional author writing print articles for web developers and wrote many articles about Now - recommending it to my readers. I also have a bunch of customers with very small needs for hosting and content management. Content changes often only after several months… so actually typical Jamstack situations. I hosted them using Vercel with a paid account when they still did scaleable pricing. I also managed the domains via Vercel. The bill was just a few $ per month for the customers. Then Vercel took the gun and shot without warning… 20$ per month… I had to quickly react to get my customers off this service. They even changed the free layer so that my customers wouldn’t be able to use it - because the websites essentially promote local services.

with Tina.io I currently see a similar situation. None of my customers would pay the monthly price of the team layer. 29$ for a CMS that is used every few months? I could recommend them the free layer and this would be similar to Forestry, which I also did recommend in the past. If this free layer would be guaranteed to exist at least until a self hosted version is made available, I could live with the situation.

I already started a print article about Tina CMS… I think I will hold this back until I know that TinaCMS doesn’t turn out as another service like Vercel.

[genox]

None of my customers would pay the monthly price of the team layer. 29$ for a CMS that is used every few months?

Yeah, that's the huge pain point I have with headless CMS with SaaS models in general. The largest part of websites is built once and updated a couple of times during its entire lifecycle. Clients don't want to write blog articles, they usually write content once right at the start and then the update frequency steadily declines until the page is binned and someone else makes their new website (or the branding changes, or the marketing manager is replaced with a new one .. ;) ).

So monthly per user pricing at this price-point does not really reflect the usage pattern for a service like that. And that is exactly what feels off about it. Hard to explain, hard to grasp. It could be much easier. Granted, 2 users free is nice, but it doesn't seem very professional in 2022 to tell a client "use your info@domain address so we only need 2 users, share the password with whomever does translations, et cetera. I will use the other account as the admin account". Most micro projects get away with 2 users too, so that is not the issue and it is essentially a generous offering. But it doesn't scale nicely and it completely ignores the reality that the number of people involved has nothing to do with the amount of budget involved.

Let us pay for admin api hits, content saving and metrics, traffic generated or CDN locations. Offer a 5$ flatrate as base price per project so that it feels like the web hosting of yesteryear. Include some small amount of said metrics in a bulk package and allow to upgrade based on usage or a prepaid package. Charge the enterprise fees for enterprise features. Implement SSO/Oauth on demand for 150$/month or something like that. I can tell you that with such a model, I wouldn't even think about self hosting, unless the client org is really adamant about it. in my opinion, the pricing model of sanity.io is - sane and they still managed to get enough enterprise customers to grow. And they get away without even offering a self hosted solution, they gained a lot of trust and the pricing is stable and makes sense because it is leaning towards paying for consumption and accounts for usage fluctuations to some degree.

I should be able to make a user for anyone I would like, sharing passwords is dumb, always has been. Maybe enterprise works different, their budgets are massive compared to all small businesses so why should they care, but enterprise isn't really known to be either efficient or pragmatic and not comparable to mom and pop shops or even a 30 ppl CNC milling shop down the road.

[scottgallant]

Thanks again for sharing your perspective here, everyone. I've worked with many clients who would not have the budget for our $29/month plan too. I get it.

As I mentioned earlier, we're strongly considering a self hosted alternative to Tina Cloud. Unfortunately we don’t have a self-hosted solution in place now because we decided to release Tina Cloud first to fund our team while we build the product. I understand that some people may not choose Tina until a self-hosted solution exists.

Going forward, please post to this discussion for pricing-specific topics. I started a new thread because we'd like to keep this one focused on self-hosting Tina.

[onionhammer]

Interesting; Forestry's pricing is $749 per month for unlimited sites but Tina's is $549/site/month.. and that doesnt even include SSO.

[scottgallant]

@onionhammer can you please post your comment to this thread? #3372

[dasmeet]

Self-hosted would help a lot. Especially for smaller sites with infrequent updates.

Something like Directus (self-hosted + cloud model) would be excellent, IMO.

[AlanBreck]

Working for a company focused on privacy and security, we have an emphasis on owning as much of our content on our own systems, or at least existing, systems as possible. Self-hosted would be a must for my use case.

[mtnstar]

Hi

thx for creating this awesome CMS !

I was able to use a self hosted version just by changing the build command in package.json:

"build": "tinacms dev -c \"next build\"",

I'm also removing the admin directory in the out folder during the github action build.

This way I can use your awesome GUI for editing my page locally and then deploy it to my production server without editing functionality.

[niutech]

You can even use inotifywait to automatically commit & push saved Markdown files to the repo.

[lacymorrow]

Worth it for small personal projects and enterprise projects alike.

[scottgallant]

Hey @lacymorrow, from your experience would large enterprise prefer to self-host of use the Saas service?

[lacymorrow]

For personal projects, I like to be in complete control of my codebase.

The reason I use TinaCMS is that my "Codebase" is my markdown content and Tina is just making git commits to my codebase.

[ricofix]

As an enterprise user [not currently large, but done IT at a Fortune100 company] I think that something you can pay for but that doesn't have lock-in is the sweet spot. Mostly companies of a certain size don't want to use free stuff, but they also don't want to be left hanging if a company [that contains crucial documentation] disappears on them.

[scottgallant]

Very well said, @ricofix . We just decided we're going to release our self-hosted stuff under an open-source license. More on that soon :)

[guilherme-marin]

I have a website generator that uses Vercel's platforms implementation, which ends up being multi-tenant project for websites. This implementation is a single project inside a monorepo at my company and I don't know how it can fit into the billing model and structure of Tina Cloud, for three reasons:

1. High price for my public - price for SSO is starting at $599.00/per project, and as far as I understand, in my use case, everything has to be in the same repository, so it will be one project in Tina's Cloud, and I'ill have to deal with authorization myself, since it's a multi-tenant app
2. Folders for a multi-tenant app (my use case) - I'm concerned about the CI, about the folder structure and how heavier this repository will get in a short period of time
3. Coupled Editor? - As far as I understood, the editor in production is linked to the tina cloud, so it is not possible in production to use only the editor independently, and send the output resources (.md/.mdx) to an S3/CloudFront for example (since in my business I don't need having control of updates through a repository, I use a database for that).

Today, what would perfectly suit my company's use case would be to somehow decouple the editor/contextual editor from Tina Cloud. Taking this opportunity, if it is possible, what would be the easiest way to achieve that?

[scottgallant]

Thanks for describing your project. I'm interested in exploring this more. Can you reach out to me at my firstname at tina.io?

[michael-collins]

My use case is makes a great case for a self-hosted version. I work in education and I can't legally post some content/data outside of University servers. I've been searching for a self-hosted solution like this for years.

[jannepeltola]

We are a non-profit organization with a small budget, but a large number of occasional contributors (our entire volunteer pool). It would be possible to create shared logins, but that's definitely not security best practice.

Non-profit pricing would help as well, but self-hosting would be nice as we have skilled technical contributors available.

[Simon99de]

My use cases would be the tina+ website on a Plesk server (no SSH access).
Access setup via URL + change data manually.

Or website on plesk and tina on my nas via docker container. (FTP connection)

[ragecc]

I haven't tried it yet, but I plan to. I clicked to put in my vote for a fully self hostable option. Just from reading about it was enough to get me interested. I'm always tinkering with things and self hosting seems to be growing. I keep finding more communities that are clustered from all the things I find through other developers repos. Docker is a large reason and I'm seeing kubernetes mentioned and showing up way more in the past month. If there is a newsletter or mailing list put me on it. My username @gmail.com Thanks

[erik06]

We will likely choose the hosted or self-hosted if we have the chance to not have to publish the CMS along with our site assets. Reason being - Security, we don't want visitors being able to go to ourwebsite.com/admin and then trying to log in. We actually like to hide the fact that we are using Tina at all. Our site asset output should be a clean directory free of CMS assets, or any reference to what technology stack we are using. Due to the nature of our business, we are often subject to Spam, Brute force attacks, and phishing scams. Hiding our technology stack makes it more difficult to spoof our sites.

[kldavis4]

Hey @erik06, just wanted to clarify for the self-hosted discussion, that the /admin route is independent of whether you are self-hosting or not. You can deploy your production site without /admin even if using Tina Cloud and produce site asset output free of the CMS.

[niutech]

You can host Tina CMS on another server and automatically commit & push changes on save using inotifywait. You can also protect a subdirectory using basic authentication.

[erik06]

@kldavis4 thanks for the clarification!

[airtonix]

If netlifycms can edit git files from the browser, make PRs all without requiring a server then the only reason i see that Tina doesn't do this is because they set out to lock people in from the start.

Not even sure why a jamstack cms would want to do anything about caching responses in prod... that should be a non issue because there should only be one user making requests... the build server.

[jamespohalloran]

Not even sure why a jamstack cms would want to do anything about caching responses in prod... that should be a non issue because there should only be one user making requests... the build server.

A few main reasons!

• Serverside rendering, ISR, etc are becoming more popular, so caching the content allows us to provide more ways to fetch your data, in addition to static builds.
• We're able to provide more advanced CMS functionality: E.g: referencing different documents in a dropdown, built-in search (coming soon), etc. Relying on GitHub's API wouldn't allow us to query on a documents frontmatter, or create connections between documents.

[logan-anderson]

Hello everyone!

Today we are excited to bring you the first version of our self hosted solution. You can now self host the “Tina Data Layer” if you want an alternative to Tina Cloud.

Please see this Github discussion for more details.