My experiences with Cockpit in production environments

Hey folks :wave:

I don’t know if this is something a lot of you care about since you’re already browsing around in the forum, but nevertheless I’ve decided to talk about my experiences with Cockpit now that I’m using it live for multiple websites.
I feel like this might be interesting for those who’re still thinking about using Cockpit.

:page_with_curl: Contents

:rocket: The beginning

I was looking for a headless cms that provides a simple, but yet versatile, REST API. Especially the REST part was important to me because I’m really not a fan of GraphQL and other solutions like it.
REST is just the easiest way of connecting client and server through javascript in my opinion.

The reason for why I needed a headless cms in the first place was, that I love developing my own frontends for websites instead of using bulky, overpowered CMS’s like WordPress. Also, at least in my opinion, it’s not easy to develop custom frontend for such CMS solutions.
However, this comes with two downsides:

  1. If you’re working for clients, they can’t change anything without working in your code, which is something nobody wants for a lot of reasons.
  2. Even if the page is just for yourself, it’s not super convenient to adjust source code just because of a typo for example. This problem becomes even bigger of an issue if you’re using some kind of pipeline for building and deploying your page, because than even micro adjustments will take some time to appear and the whole process becomes more and more comlpex.

Pretty quickly I than found Cockpit, and the first glance was really good already. It’s open source, the docs are well written, and the community seamed pretty active (which it indeed is as I can say now :heart:).

:gear: Figuring things out

I started to read the docs which was super straight forward. I’m the type of person who checks out the documentation before starting any installing, because I think that if the docs aren’t good, you’ll have a hard time working with the repo/software overall.

Chances are that if the docs are good, so is the repo it describes. At least from my experience that is.

After making sure that the docs are good, I proceeded to the installation of cockpit. It was as easy as it gets … Huge plus! :star_struck:

Just something I want to suggest new Cockpit users: If you want to use Cockpit as a headless CMS, dedicated to a specific site, I recommend running Cockpit on a subdomain of the site. That makes everything way easier compared to running Cockpit in a sub-directory.
Example:

Frontend: mypage.com
CMS: cockpit.mypage.com

By doing it that way, you have two completely independent environments that don’t interfere with each other.

:pen: Building a frontend

Just for reference: I’m working with VueJS (plain, no CLI) and LESS.

After I’ve set up Cockpit in my test environment, I was super hyped about using the REST API and writing some frontend code. As it turned out, this was just as comfortable and straight forward as the installation process. Walk in the park :sunglasses:
Because I knew from the beginning that I want to use the chosen headless CMS for multiple pages, I started working on a dynamic frontend solution that is easy to set up so I could launch Cockpit sites quickly. After getting deeper and deeper into the whole Cockpit topic, I decided to start a open source repo so others can use my frontend as well. That’s how my project COF - Cockpit Frontend came together. Feel free to check it out on GitLab. But don’t use it unless you’ve already taken a look into how Cockpit works.

TL;DR: I now have a dynamic and universal frontend solution that allows me to build new pages quickly. 100% custom but yet easy to maintain. Just what I wanted right from the beginning.

:watch: How it’s going

I’m using Cockpit for four live websites now.
On three of those, Cockpit actually supplies all of the page contents. In one case even with two languages.
One of those three is for a medium sized company with up to about 300 website visitors a day. Cockpit handles those loads without any hickups.
On the fourth page, I only use Cockpit for some components which are the gallery and the contact form.
The gallery links to a collection that is linked to some photos which are stored in Cockpits build-in asset manager. The contact form just links to a… well you’ve guess it… form.
This allows me to change my gallery photos and receive contact requests via E-Mail while also keeping them in Cockpit.

:interrobang: Conclusion

What are you waiting for? Do it! Cockpit is great fun to use, the setup is easy, and the REST API is fast, easy to learn, and can be customized to fit your needs.

This might sound like some marketing team payed me to write all of that lmao. But seriously, give it a try. You won’t regret it :smile:

With all that said, have a great day :v:

4 Likes

I’ve been using Cockpit for 2 years now and never regret it. Before that I tried a bunch of Headless CMS(s), most of their features are not dynamic (changeable) like Cockpit.

My favorite features of Cockpit are

  • Super easy to build my own addon
  • With Cockpit API, I can even search the whole content like full text search with regex. (Most CMS don’t have this feature)
  • I can serve multiple websites for my clients with just a single Cockpit API. Clients can login and manage their content without seeing other client content.
  • Advanced authentication and authorization, protect CRUD, fields based on user roles.
  • Deployment is very easy, just upload to the PHP server and it’s done.
  • It's free! , we can use a full features of headless CMS without any extra charges.
2 Likes

Thank you for your extensive review!

We have been using Cockpit for a while too. In fact it’s now the official headless CMS solution for VisualNEO Web (our app development tool) and we have developed a plugin to connect both so it makes super easy to create client side applications that connect to Cockpit CMS to get the contents.

This is an example on how to search and get posts with just three lines of code using neoScript:

neoCmsSetUrl “cms” “https://mycms.mydomainname.com/
neoCmsSetToken “cms” “xxxxxxxxxxxxxxxxxxxxxx”
neoCmsSearchCollection “cms” “posts” “” “title_slug” [slug] “Exact match” 1 0 “_modified” “Descending” [postInfo] [error] “parsePost”

The speed is awesome and we get a lightweight solution with custom design :slight_smile:

1 Like