Nibble

Nibble is a content management system you run as your own application. You clone it, install it, and it becomes your site — your theme, your content, your server. There is no account to sign up for, no plan to outgrow, and nothing phoning home.

If you have used WordPress the shape will be familiar: people write in a control panel, and visitors see a site. What is different is where the definitions live. In Nibble, the things that decide what your content looks like — the collections, the fields, the navigation — are small files you keep alongside the rest of your site. Change a file and the control panel changes with it.

Is Nibble for you?

It suits you if you want a site you fully own, are comfortable with a terminal and a git repository — or work alongside someone who is — and would rather write a page’s structure down once than click it together again on every new site.

It is probably not for you if you want to install a CMS by uploading files to shared hosting and run it entirely from a browser. Nibble expects a deploy step.

How this documentation is organised

Each section is written for a different day of work. Start wherever you are; you do not have to read them in order, or at all.

If you are	Start here	It covers
setting a site up and keeping it running	Running a site	installing, settings, users, upgrades, backups
writing and publishing the content	Editing content	entries, assets, publishing, forms, SEO
making the site look like something	Building a theme	schema, blueprints, views, queries
adding behaviour of your own	Extending Nibble	the seams Nibble leaves for you
working on Nibble itself	Developing Nibble	architecture, tests, releases

Most people running a small site need Running a site and Editing content and nothing else.

The idea in one page

Your content is rows; its shape is files. A blueprint is a file listing the fields a page has. A collection is a file saying that blog posts exist, live at /blog/{slug}, and use that blueprint. When someone writes a post in the control panel the post itself is a row in the database — but what a post is was decided by a file you can read, review and roll back.

A few consequences are worth knowing up front:

• Two sites cannot drift apart by accident. Staging has the same fields as production because it has the same files.
• A change of shape is reviewable. Adding a field to every post is a line in a file, seen in a pull request, rather than a click nobody witnessed.
• Content can be written as files too, when that suits it better. A folder of Markdown can be a collection — these documentation pages are exactly that. See Content written as files.

What belongs to you

Everything under lib/nibble/ is Nibble’s. Everything else is yours — including app/, so your own models, controllers and jobs sit exactly where a Rails application puts them, with nothing of ours in the way.

When you need to change one of Nibble’s own files, do not edit it in place. Run:

bin/rails nibble:eject app/views/layouts/mailer.html.erb

That copies the file somewhere yours is found first, and records that you now maintain it. Afterwards bin/rails nibble:check tells you when Nibble’s original moves on, so you can decide whether to follow — and it reports anything of Nibble’s you changed without ejecting, which is exactly what an upgrade would otherwise stop on.

Getting started

./install.sh my-site
cd my-site
bin/dev

Then open http://localhost:3100 for the site and http://localhost:3100/admin for the control panel. The full walkthrough, including what the installer asks and why, is in Installing.