The Zendesk Copenhagen Theme
The Copenhagen theme is where every Zendesk help centre starts. Forking it is easy. Living with the fork for three years is the part nobody costs out.
What the Copenhagen theme in Zendesk actually is
Copenhagen is the default Zendesk Guide theme. It's what your help centre looks like the day you turn it on, and Zendesk maintains it, publishes the source publicly, and updates it when Guide gains a feature that needs new markup.
That last point is the whole article. Your help centre runs on a copy of Copenhagen, and the copy is either the managed one Zendesk keeps current, or one you took a snapshot of and now own forever.
It's a genuinely decent theme. Accessible markup, a sensible search-first home page, responsive without being fussy. Plenty of companies never need anything else. The instinct to replace it usually comes from a designer looking at a screenshot rather than from anybody looking at the numbers.
How the theme is put together
A Guide theme is a folder with a fixed shape. Roughly this:
manifest.json
settings/
assets/
templates/
document_head.hbs
header.hbs
footer.hbs
home_page.hbs
category_page.hbs
section_page.hbs
article_page.hbs
new_request_page.hbs
search_results.hbs
style.css
script.jsThe templates are Handlebars files. Zendesk supplies the data and a set of its own helpers, and you lay it out. manifest.json declares the theme name, the templating API version it targets, and the settings that show up in the theme editor panel.
That settings file is the bit worth understanding before you write any code. Anything you expose as a setting can be changed later by a marketing person in the admin interface. Anything you hard-code into a template needs a developer and a redeploy. Same visual result, wildly different maintenance cost.
Forking it
Zendesk publishes Copenhagen on GitHub. The normal route is to fork the repo, work locally, and import the result as a new theme rather than editing the live one.
Check the current Zendesk docs for the repo location and the exact CLI commands, since both have moved over the years.
The upgrade problem
Here's the trade nobody explains at the start. The stock Copenhagen theme gets updated for you. Your fork doesn't.
When Zendesk ships a Guide feature that needs new template markup, and it does, accounts on the managed theme get it. Accounts on a two-year-old fork get nothing, or worse, get a half-working version because the feature depends on a helper the old templates never call.
The failure mode is boring and predictable. Somebody forked in year one, that developer left in year two, and by year three nobody can safely touch the theme, so the help centre quietly stops gaining features while everything else in Zendesk moves on.
You can absolutely run a fork well. It needs an owner, a habit of pulling upstream a few times a year, and small diffs. If you can't commit to all three, don't fork.
The middle path most teams should take
Try the changes in this order and stop as soon as you're happy.
For the settings-only route and what it covers, see help center branding. For the wider theme landscape, Guide themes goes into buying versus building.
Frequently asked questions
What happens after you fork Copenhagen theme files?
You own them. Fork Copenhagen theme code and Zendesk stops updating it for you, so every improvement they ship afterwards has to be merged in by hand or ignored.
Should you fork Copenhagen or copy from GitHub?
Fork Copenhagen from within Guide if you can, because it tracks the version you're on. The Copenhagen theme GitHub repository is the reference, and copying from it means you own every future update.
Where is the Zendesk Copenhagen theme source code?
Zendesk publishes it in a public GitHub repository. Check the current Guide developer docs for the exact repo, since the location and the templating API version have both changed over time.
Does forking Copenhagen break future Zendesk updates?
It doesn't break them, it just stops receiving them. Your forked copy stays frozen at the version you took, so new Guide features that need template changes won't appear until you merge upstream yourself.
Can I edit Copenhagen without forking it?
You can change the exposed settings on the live theme. Editing code means creating a copy, and at that point you own it, whether or not you used git to do it.
Do I need a developer for Copenhagen?
Not for colours, fonts, logo and the layout toggles in the settings panel. Yes for anything that changes structure, since that means Handlebars templates, CSS and sometimes JavaScript.
A better help centre still gets duplicates
Self-service deflects some volume. For the tickets that still arrive twice, Ticket Merger finds the pairs automatically.
Start free trial14-day free trial. No credit card required.