What’s new

A GitGumbo project syncs on one credential. That is fine when you are working alone and becomes a real problem the moment a board is shared: every member was seeing whatever the syncing account could see, which is not necessarily what they could see.

Marking confidential issues made this impossible to ignore. A confidential issue was arriving on the board with its title, its labels and its assignees, shown to every member of the firm — including members who would get a 404 opening that same issue in GitLab directly. We had made the board honest about what the issue was without answering who should be looking at it.

Visibility is now resolved per viewer. When you open a shared board, what renders is checked against your own provider account, not against the account that happens to run the sync. Everyone signs in with a provider account already, so the identity needed to do this was there the whole time.

One limit, stated plainly

Titles, references and links for issues above your access level are withheld. The counts on the blocked and blocking indicators are not per-viewer — they are denormalised, and making them viewer-specific needs per-link confidentiality that we do not currently store.

So a member below the access floor can learn that an issue has, say, two links, without learning what either of them is. That is a deliberate residual rather than an oversight, and it is written down as one.

GitLab's issue page has a button that creates a merge request and a branch for that issue. It is genuinely one of the better things about that page, and using it meant leaving GitGumbo.

Cards now have it. Create a merge request straight from the card, on GitLab boards, and it does what the provider's own button does — creates the branch, opens the merge request, and links it back to the issue so closing one closes the other.

It creates a draft. That is deliberate, and it was a real bug for a couple of days before it was fixed: a button that opens a review-ready merge request the moment you click it is a button that pings reviewers about work that does not exist yet. Drafts are the right default for something created at the start of a piece of work. Mark it ready when it is.

GitHub does not have an equivalent for this yet on our side, and the card knows that rather than offering a control that would fail.

Dates in GitGumbo used to be written one way for everyone. That was not a policy anyone chose; it was the default that arrived with the first date that needed rendering and was never revisited.

There is now a Date format setting with three options:

• Day first — 18/08/2026
• Month first — 08/18/2026
• ISO — 2026-08-18

It applies everywhere a date is shown: due dates on cards, sync timestamps, billing dates, the lot.

If you are signed out we take a sensible guess from your browser's language preference rather than showing you the same fixed format regardless. If you are signed in, your choice wins, on every device.

A note for anyone who has to reason about the difference: 08/09/2026 means two different days depending on which side of an ocean you learned to write dates on, and no amount of context makes that ambiguity safe. That is why the numeric formats are the ones offered, and why ISO is there for people who would rather not gamble.

GitGumbo mirrors your issues so it can render a board without hammering your provider on every page load. That mirror includes issue titles, and issue titles are, by some distance, the most revealing thing in our database. "Fix the login loop" is harmless. Plenty of real ones are not.

Until now they sat in Postgres as plaintext, and — the part that actually mattered — they left the machine that way every night in the backup.

What changed

Titles are encrypted in the database. The application encrypts on write and decrypts on read, so the values in the table are ciphertext.

The nightly backup is encrypted too, independently. A backup is a copy of your data that lives somewhere else by design, which makes it the copy most worth protecting and the one easiest to forget. We have run a restore drill against the encrypted backups to confirm they are not merely encrypted but actually recoverable — an untested backup is a belief, not a backup.

The old plaintext columns have been dropped, not just left unused. A column nobody reads is still a column that is there, still in every dump, still one careless query away from being read again.

Why it took four deploys

Dropping a column in a live system is not one change, it is two. For the length of a deploy, the previously-deployed code is running against the newly-migrated schema. So a migration that removes something the running code still expects takes the site down in the gap.

The safe shape is expand, then contract: add the new columns and write to both, move reads across, stop writing the old ones, and only then — in a later deploy, once nothing running refers to them — drop them. Four steps, four deploys, no window in which the code and the schema disagree.

The interesting part was finding every reader. It is tempting to grep for the column name and conclude that nothing references it, but that is a claim about your source code when the thing that matters is the generated SQL. Prisma projects every scalar field on a model unless you explicitly narrow the selection, so seven query sites were reading those columns without ever naming them. A single-deploy contract phase would have taken out four write paths.

What this is not

This is encryption at rest, and it is honest to be precise about what that covers. It protects the data in the database file and in the backups. It does not make us unable to read your issue titles — the application decrypts them to draw your board, which is the whole point of the board. If you need a provider that cannot read your data at all, that is a different product than this one.

GitHub added issue dependencies, and the relationships turned out to be present in responses we were already fetching. So the blocked and blocking indicators built for GitLab boards now work on GitHub boards too — same card indicators, same hover highlighting, same connector lines, same Blocking filter.

Nothing about your board configuration needs to change.

One honest note about freshness. A change to a dependency does not always register as a change to the issue itself on GitHub's side, which means it will not necessarily arrive on the next incremental sweep the way an edit to a title would. It settles on the fuller reconciliation that runs underneath. If a dependency you have just set is not showing yet, that is why, and Sync now will fetch it.

GitLab knows which issues block which other issues. That information was sitting in the API and nowhere on your board. Now it is on the board, in both directions.

• A card that is blocked by something shows it, with a count.
• A card that is blocking something shows that too. This is the direction people actually need and the one tools usually omit: knowing you are stuck is useful, knowing that you are the reason three other things are stuck is what changes what you do next.
• Hovering a blocked or blocking chip highlights the linked cards and draws connector lines between them, across columns. Click to pin the trail so it stays while you look at it.
• There is a Blocking filter on the board controls, beside Blocked.

Confidential issues are marked

Shipping in the same window, and overdue: GitLab confidential issues were being rendered exactly like public ones. Nothing on the card said the issue was restricted.

They are now marked as confidential on the board. An issue whose whole point is that it is not for general circulation should not look identical to one that is, particularly on a screen that is often the one being shared in a meeting.

Two new themes, and they are not colour variations of the existing ones.

Index Card draws cards as ruled index cards, on a surface that looks like a desk rather than a screen. Post-it draws them as sticky notes.

There is a serious reason underneath the fun one. A lot of people ran their best boards on a wall with actual cards, and the thing they miss is not nostalgia, it is that a physical card is easier to hold in your head as an object. The skeuomorphic version gets closer to that than a flat rectangle does.

Both work with card density, drag-and-drop and every card feature. The card title gets its own row in these two themes, which is a small change that makes a handwritten-looking card legible instead of cramped.

One caveat, stated up front: these two themes are the weakest place in the product for contrast, and the higher-contrast accessibility setting does not currently reach the card borders they draw. If you rely on that setting, the other themes serve you better today. More on that in accessibility, and the difference between a claim and a measurement.

There is now a Switch to Free control on the billing page.

Signing up took about a minute. Leaving used to take an email and a wait. That asymmetry is a design choice wherever it appears, and it is not one we want to have made, so: it is a button, it sits on the billing page next to the controls that got you here, and it asks for confirmation once because it changes what you are paying for.

Your data does not go anywhere. You keep your boards. What changes is the plan's limits and cadences — Free syncs from your provider every 15 minutes rather than every 5, and drops the webhook. Manual Sync now and the per-card refresh keep working exactly as before; those are not plan-gated on any tier.

Dragging a card between columns has always moved it between stages. Dragging a card within its column now sets its position there, on GitLab boards, and the order is written back rather than being a local rearrangement that the next sync undoes.

There is a keyboard and switch-accessible path to the same result, and it is not a drag with a keyboard bolted on. Drag is a poor primitive to emulate: it needs pointer precision and continuous input, and the accessible version of "pick this up, move it, put it down" is usually a menu that names the destination rather than a simulation of the gesture. So card placement and column reordering both have a real menu-driven route, which is quicker than dragging even if you have no reason to need it.

One thing found while building this and worth recording: our GitLab reorder call was sending the inverted direction, so every drag wrote the opposite placement to the one performed. That is fixed. Reordering is also the kind of change that does not always register as an update on the provider's side, so the ordering is reconciled on a slower schedule underneath the fast path.

Columns can now carry a work-in-progress limit. Set one, and the column shows its count against the limit and flags when it is over.

The more interesting half of this release is what happens when a column cannot have one. Where the limit comes from depends on how the board is defined, and on a provider-driven board the answer is sometimes "not from here". Previously that just looked like a column with no limit, which is indistinguishable from a column nobody set a limit on.

Now the board explains why the limit is missing and where it would have to be set instead. Same principle as the non-label columns: an absence you cannot account for is worse than a message.

Not every GitLab board is built from labels. GitLab lets a list be defined by an assignee or a milestone, and a board mixing those with label lists was previously rendering only part of itself.

Those lists now render.

Two related fixes came with it, and the second matters more than it looks:

• Moving a card into a non-label column no longer causes the card to vanish from the board on the next fetch.
• A board that still has lists we cannot draw now tells you so on the board, naming what is missing.

That second one is the point. The old behaviour was not "unsupported", it was "silently incomplete" — a board that looked whole and was not, with no way to tell the difference from the outside. A tool that cannot show you something should say which thing, not present a partial answer as a full one.

Cards now carry two things that previously required opening the issue to find out: the milestone it belongs to and the date it is due.

The milestone renders as a pill and the due date as a chip, with the chip reflecting how close the date is, so an overdue card looks overdue at a glance rather than after arithmetic.

Both are mapped on GitLab and GitHub. GitHub calls the due date something different on its side, which is our problem rather than yours.

Both fields are also on the v1 API's issue payload, so anything you have built against it can see them too.

Cards carry a lot now — title, labels, assignees, milestone, due date, pipeline status, blocked indicators. That is useful when you are looking at a card and in the way when you are looking at a board.

There is now a density toggle. Minimized cards drop to a compact row, which on a busy column is the difference between seeing four cards and seeing a dozen.

Nothing is filtered out and nothing is lost — the cards are the same cards, drawn shorter. Switch back when you want the detail. The setting sticks, so if you work minimized you do not have to say so every morning.

The theme picker has grown up.

• Light and Dark — the obvious two.
• High Contrast — for when the default borders and text are not doing enough.
• Gruvbox and Dracula — two palettes that people already have opinions about, done properly rather than approximated.
• System — follow whatever your operating system is doing, and change when it changes.

System is the default, and it is the one most people should leave alone: a laptop that goes dark at sunset should take GitGumbo with it without anyone opening a settings page.

The picker shows each theme as a small board rather than a colour swatch, since what you actually want to know is what a card looks like in it, not what the accent colour is in isolation.

We built more palettes than shipped. Several were cut for the ordinary reason — they looked good in a screenshot and were tiring to work in — and one was cut because its contrast could not be made to hold up. A theme that fails on contrast is not a style choice, so it did not ship.

Boards are good at telling you what is happening now and bad at telling you what has been happening. There is now a stats view that answers the second question.

• Throughput and cycle time — how much is finishing, and how long it takes.
• Work in progress — how much is open per stage, and whether that number is drifting upward.
• Age distribution — where the old things are, which is usually a more useful question than how many things there are.
• Contributors and review activity — who is opening work and who is reviewing it, which are not the same list and are worth seeing side by side.

The charts read from state transitions we record as issues move, so this gets more useful the longer a board has been connected. Every chart follows the active theme, including the high-contrast one.

A board with a lot of stages gets a chart with a lot of slices, so the distribution charts cap at the eight largest and group the rest as "Other" — a pie chart with twenty wedges is a decoration, not a measurement.

A GitLab project can have more than one issue board, and plenty do — one for the team's day-to-day, one for a release, one for a particular slice of the backlog. Until now GitGumbo picked one and that was the board you got.

There is now a board switcher on the board itself, listing that project's boards alphabetically. Switching re-reads the columns from the board you picked, so a board defined around milestones and a board defined around workflow labels each render on their own terms rather than being forced through one shared column definition.

This replaced the GitLab assignee filter that used to sit in that spot. The assignee filter has not gone away — it moved into the board's filter controls, where it sits with the rest of the filtering rather than being the one filter that got its own permanent slot.

Your theme choice is now saved to your account instead of to the browser you happened to pick it in.

This sounds small and is one of those things that is quietly annoying every single time it is wrong. Pick a dark theme at your desk, open GitGumbo on a laptop that evening, get a screenful of white. Fix it there. Open it on your phone the next morning, get a screenful of white again.

Now the choice travels with you. Set it once.

If you have not chosen — and choosing is optional — we follow your operating system's light or dark preference, which is very often the right answer without anyone having to decide anything.

Until now everything in GitGumbo belonged to a single user account. That works until a second person needs to see the board, at which point the only options were sharing a password or giving up — and people do share the password, which is why we would rather build the alternative.

Projects, boards, sync history and billing now belong to a firm. Every account gets a personal firm automatically, so if you are working alone nothing about this is visible to you and nothing needs setting up.

• Invites — invite someone by email; the invite is consumed when they sign in, and consuming it is idempotent, so two simultaneous sign-ins cannot produce two memberships.
• Roles — members have roles, and the role decides what they can change rather than merely what they can see.
• One subscription per firm, billed with seats, instead of a subscription per person who happens to have connected the same project.

An invite that has been sent but not accepted still holds a paid seat, which we consider a bug in waiting rather than a feature, and expiry is on the list.

GitGumbo now has plans and a way to pay for them.

• Checkout runs through Stripe. Monthly or yearly.
• A self-serve billing portal, so payment details, invoices and cancellation are yours to manage without emailing anybody.
• Project limits follow your plan, enforced at the point where a project is connected rather than discovered later.

Free stays genuinely usable rather than being a demo with a timer on it. The practical difference is how quickly changes reach you: Free syncs from your provider every 15 minutes, Pro every 5 minutes plus webhooks. Manual Sync now and the per-card refresh are not plan-gated on any tier — see how your board stays current for what each of those numbers actually measures.

Current pricing is on the pricing page, which is also the only place we state it — every surface that shows a price reads from one source, so there is no second copy to go stale.

Until now every change reached your board by us going and asking for it on a schedule. Now your provider can tell us.

GitHub and GitLab webhooks are both supported, and registration is automatic — connect a project and we register the hook.

The GitLab side needed more care than expected. Registering a project hook requires a token with the right scope, and if the token does not have it, GitLab does not refuse loudly. Registration can appear to succeed while producing a hook that never fires, which is the worst of both worlds: a board that looks connected and quietly is not. So registration checks the scope up front, across your linked GitLab accounts, and tells you when nothing available can do the job.

The scheduled sweep has not gone anywhere and is not going to. Webhooks get dropped, providers have incidents, and a system with only one path for changes to arrive has a single point of silence.

GitGumbo started life as a list of stale merge requests. It now draws a board.

Issues render as cards in columns, and the columns are built from your project's existing labels. We read the board configuration your project already has rather than asking you to re-describe your workflow to another tool — if your team has agreed that status::in-review means in review, that agreement is the configuration, and duplicating it here would only give the two copies a chance to disagree.

Also in this release:

• Collapsible columns, because a board with nine stages does not fit on a laptop and the two you are not working in today do not need the width.
• Column labels styled as the provider's own coloured badges, so a label looks the same here as it does where you set it.
• Filtering across the board.
• Columns fill the full height of the viewport rather than stopping at an arbitrary cap, which sounds like a detail and is the difference between scrolling one thing and scrolling two.