Why we've created "yet another cms"

We've developed the play-cms out of our needs for a large client project (online shop for a major swiss publisher). Play framework was the perfect fit, but there is no cms around. The requirements were too specific for a generic system, yet the client's web team required a good deal of cms functionality. Our main priority was to create a flexible play-based cms that supports you instead of standing in your way when developing a custom client solution. And since it was not our first cms, we gave it a spin.

When to use the insign play-cms

  • If you need cms capabilities in your play project
  • If your app needs authentication/authorisation
  • If you want a deep and ready-to-use integration between cms and your custom play application

When NOT to use insign play-cms

  • If you need a full-blown cms solution with enterprise features such as Magnolia or Alfresco
  • If you need workflow capabilities (although you could enhance the play-cms in that direction)
  • .. and you're ok to not use the Play framework

Feature overview

  • Powerful yet light-weight cms - made for custom projects that require cms capabilities
  • Content block based architecture - basic blocks provided - add your own blocks
  • Comfortable authoring: WYSIWYG, frontend controls, drag and drop content blocks on the page - or pages in the navigation tree etc.
  • Time-based publishing and unpublishing
  • Role-based permission system: 
    • Manage users and roles from the backend
    • Assign inheritable permissions to content blocks and pages
    • Use these permissions everywhere within your application (annotation-based controller actions, or in code)
    • Integrate with your own user provider
  • Various ways to integrate your application
    • In-page: Create custom content blocks that can be placed everywhere throughout the site
    • Whole-page: Create whole pages (where you control the url routing) and integrate cms features such as the navigation
    • In-content: Create custom filters that replace variables used in the wysiwyg editor with your own dynamic data
  • Powerful and customizable caching patterns: Page-level caching, block-level caching, individual cache expiry settings etc.



The insign play modules are based on JPA2 for easy and powerful ORM-based persistence, and can use any JPA2-compatible storage backend (we use MySQL).

This is a typical project structure:

Other noteworthy components:

  • Fulltext search: Elastic search/index provider integrated, custom provider(s) can be added
  • WYSIWYG editor: TinyMCE
  • Media library: Optional MoxieManager provider, or add a custom provider
  • Security: play-auth is based on Apache Shiro and allows fine-grained, role-based permissions to content blocks
  • Java 8


CMS Modules

The insign play-cms consists of the following modules:



Content management system


Documentation >



Authentication & Authorisation framework, based on Apache Shiro


Documentation >



Common tools & utilities used by all modules

Repo: https://git.insign.rocks/open-source/play-cms/play-cms/tree/master/modules/play-commons

Documentation >



Default backend admin theme


Note: The theme used is Metronic



CMS Demo Project (play-cms-demo)

To help you getting started with play-cms, you can clone/fork our Demo-Project found here: https://git.insign.rocks/open-source/play-cms/demo (see its README for the various installation methods).

Read more about the Demo-Project in the CMS-Demo Documenation


How to contribute

Missing a feature? Found a bug? Code contributions are very welcome! To contribute, please fork the repository and create a PR with your code.

Alternatively, create a bug report or feature wish issue using the GitLab issue tracker.

Feel free to contact us in the play-cms community for further discussions, questions etc.



play-cms is licensed under the Apache 2 license