Reviewing Cockpit

I’m the Tech Lead at an advertising agency seeking to potentially use Cockpit Pro. I’ve ultimately decided that Cockpit isn’t the right choice for us but since I see so much potential in this product, I’d like to leave the pros and cons I’ve encountered here in hopes that it helps aid its progress as it evolves.

Our goal was to utilize Cockpit as a way of managing content that would be consumed by a NextJS server. We currently utilize WordPress in that manner, but its age leaves a lot to be desired in terms of the way you have to manage its codebase (among other things).

The following pros and cons should be understood with our goals in mind.


  • Incredibly clean source code (especially when compared to WordPress).
  • Minimal UI (lack of clutter to confuse users).
  • Many features we expect from WP also present in Cockpit (where appropriate for a headless CMS)
    – Revision history, component-oriented page building, comprehensive field-types for component configurations, common page-level configurations, asset management, and excellent page preview system
  • Additional features we wish we had on WP
    – Sync, Webhooks, clean API and role management


  • Documentation is extremely sparse
    – This was one of the biggest killers. I understand that a lot can be accomplished by looking at these very forums and at existing code but it’s very hard to recommend any product if documentation doesn’t at least cover the most likely tasks devs will encounter (the anatomy of an addon,
  • Incomplete GraphQL support.
    – I know this is a known issue but it was disappointing nonetheless.
  • Tree data management didn’t work for me.
    – It’s possible I’m doing something wrong here but as the first point states, there isn’t even a good place to look for common problems to quickly get over this issue. And again, no, forums are not documentation.
  • No email support
    – In WordPress, it’s a matter of installing some SMTP plugin and hook it up to an SMTP provider to reliably be able to send emails to desired users. I would’ve been fine assuming we would have to create an addon… if there was official documentation for it.
  • MongoDB
    – I put this down as a con because while on the surface it’s a very easy to use database, it does come with a learning curve as you dive in and contradicts a lot of previous understandings that come with typical relational database knowledge. Support for MySql would be great here so that I don’t have to expect my team to learn a new database technology. That said, if the other cons were addressed, this would probably not stop me from recommending this product.

Hope this was constructive! I totally understand being given criticism when it’s not necessarily asked for might be frustrating so I very much appreciate anyone taking the time to read this and consider it.

Maybe I’ll return to this in another couple years and it’ll blow all my expectations out of the water. :slight_smile:

1 Like

Hi Jake :wave:

I really appreciate that you took the time to leave such an extensive feedback :pray:

To address your cons:

  • Documentation is extremely sparse
    Yes, I hear you and agree with you on this one. Right now it is hard to find the right balance between working on Cockpit and new features and keeping up with the documentation :pensive: I hope to fix this in the near future.

  • Incomplete GraphQL support
    Can you provide some more details on this one? What is missing?

  • Tree data management didn’t work for me
    What’s went wrong here? Are you looking for use-cases? Or did something not work as expected?

  • No email support
    You can setup Cockpits internal mailer service to use smtp for email sending in your config file. Can you provide more information or use case for the need?

  • MongoDB
    I understand that MongoDb is not as common as an RDBMS but it provide so much more flexibility that I wouldn’t trade it in for a SQL based DB. Btw, Cockpit comes withe a (lite) MongoDB implementation on top of SQLite by default. For small to mid-size projects that should be totally fine and don’t require any external DB server. Just plag and play :wink:

Again, thank you for your valuable feedback. Any feedback is welcome! :+1:

About “incomplete GraphQL support”, could this be part of it? I can’t seem to be able to pass query variables into the query GraphQL query variables not working