What’s new

GitHub issues don't come with a board of their own. Most teams who want one build it in a GitHub Project, with a Status field for the columns. Until now a GitGumbo board could borrow those column names, but it placed and moved cards by label, so it could disagree with the Project it was named after.

Now a GitHub board can follow the Project itself.

What changed

Pick the Project. Open a GitHub board, choose Follow a GitHub Project, and pick one of the Projects linked to the repository. Projects owned by an organization and by a user account both work.

The columns are the Project's Status options. Add, rename or reorder them in GitHub and the board follows on its next sync.

Cards sit where the Project puts them. Each open issue lands in the column that matches its Status. Issues with no Status, and issues that aren't in the Project at all, go in a No Status column. The ones that aren't in the Project carry a small Not in Project marker, so you can tell the two apart.

Dragging a card changes its Status in GitHub. No labels are written. Drag a card out of No Status and, if the issue isn't in the Project yet, GitGumbo adds it and sets its Status. Drag one back into No Status and its Status is cleared, but the issue stays in the Project. Dragging to Closed closes the issue, as it does on any board.

How current it is

A drag in GitGumbo shows on the board straight away. A Status changed in GitHub takes longer to arrive: GitHub sends no webhook to a repository when a Project's Status changes, so GitGumbo reads every Status on each sync and checks again about every 10 minutes. Expect a change made in GitHub to show within about 10 minutes, or press Sync now to fetch it.

When GitGumbo can't read the Project

If GitGumbo can't read the Project, the board says so with the reason and leaves its columns and cards where they were. It won't empty a board because one read failed. The common reasons:

• A classic token needs the project scope. Signing in with GitHub already asks for it.
• A fine-grained token can't read a Project owned by a user account, and needs the Projects permission for one owned by an organization.
• An organization that restricts third-party apps has to approve GitGumbo first. An organization owner does that in the organization's settings, under Third-party access.

A card's pipeline dot shows what your provider says the pipeline is doing. If GitLab says it's running, the dot says running. That's what it should do. But a pipeline can sit in "running" for days, waiting on a job that will never start, and a dot that has said "running" since Monday looks like the board is broken. The board was right. It just wasn't telling you enough.

What changed

A clock on the dot. When a pipeline has been unfinished for three hours or more (running, queued, waiting for a runner and so on), its dot gets a small clock. The dot keeps its colour, and the card stays in its column. GitGumbo still shows your provider's verdict and doesn't replace it.

The tooltip says how long, and why. Hover the dot, or focus the merge request link, and you'll read something like:

Pipeline running for 2 days — it may be stuck. Already failed: lint. Still waiting on: deploy-review (not started after 2 days).

It names the jobs that have already failed and the ones still waiting, oldest first, so you know whether to retry a job, cancel the pipeline or go and look at your runners.

GitLab and GitHub both. On GitLab the clock starts when the pipeline was created. On GitHub it starts when the earliest unfinished check began.

What it doesn't change

The flag is information only. It doesn't move cards, change the dot's colour, or count towards anything in Stats. Three hours is a fixed threshold for now, long enough that an ordinary build never trips it.

Until now the Free plan only took public repositories. That was a poor way to try a board: most teams keep their real work in private repositories, so the board you could build on Free wasn't the one you'd use.

Free now takes private repositories too.

What changed

Add a private repository on Free. Public or private, it counts the same towards Free's repository limit. Nothing else about the plan changed: the seat, account and repository limits and the sync interval are as they were. The pricing page has the current numbers.

No new permissions. Signing in with GitHub has always asked for access to your private repositories, and GitLab sign-in already reads the projects you can see. Nobody has to grant anything new.

The same checks as before. When you add a repository, GitGumbo still confirms that the account you connected can actually see it, on every plan.

Pro is still where the extras live, such as more repositories, faster sync, webhooks, Stats and the API. You no longer need it just to put your own code on a board.

When your data moved onto an encrypted disk, one thing stayed behind: logs. Some of them can't live on the encrypted disk, because they have to be readable while the machine is still starting up. So we looked at the problem from the other side. If a log has to sit on a plain disk, it shouldn't hold anything about your work.

What changed

The request log lives in memory. The web server's record of requests used to be written to the server's ordinary disk. It's now kept in memory only, so it's gone whenever the machine restarts, and it's small enough that it only ever covers recent traffic. The tool that blocks abusive traffic still reads it, and that tool keeps none of the lines it matches.

Logs no longer carry your data. We went through everything the application, the background worker, the backups and the database write to their logs, and removed anything that identifies your work or your people:

• issue and merge request titles, label names and branch names
• names, usernames and email addresses
• repository and project paths, including inside the addresses of calls we make to GitHub and GitLab
• the text of error messages that quote any of the above

What's left is what we need to keep the service running: internal IDs, counts, timings and which step failed. The database now logs errors briefly too, so a failed query doesn't copy its values into the log.

Webhooks keep less. A webhook from GitHub or GitLab waiting to be processed no longer stores the repository's path. GitGumbo only needs its ID.

What this is not

Logs are how we find and fix problems, so we still keep them. What changed is what they contain. A copy of our logs now tells someone that a sync ran and how long it took. It doesn't tell them what your team is working on.

A 14-day trial ends quietly if nobody is watching the date. Two things now make sure someone is.

A week before the trial ends, Stripe emails a reminder to the address used at checkout. That email has always gone out; we have now confirmed it on a live trial, seven days before the end, so we can say so here.

Then, for the last three days, owners and admins of the firm see a banner at the top of the app: "Your trial ends on 17 Oct 2026. Without a payment method on file, you'll go back to Free then." It links to Billing and has a close button. Closing it hides it in that browser; the same person on another device sees it again, on purpose, because a reminder dismissed once from a phone is not much of a reminder. The date is written in your own date format. Members who aren't owners or admins never see it, and neither does a firm that has already chosen not to continue.

Nothing on the banner says you will be charged, because without a card on file you won't be: the firm goes back to Free, and you can upgrade again whenever you like.

Open a Blocked, Blocking or Relates to panel and thin lines join the card to each linked card. That works while both cards are on screen. Each column scrolls on its own, though, and a linked card scrolled above or below its column's visible list still had a position, often hundreds of pixels off the board. The line aimed at that point, left the board wherever that bearing crossed its edge, and the label ended up between two columns, pointing at nothing you could find.

Now the line knows which column the card is in.

• It stops at the column. When the linked card is scrolled out of view, the line ends at the top or bottom edge of that column's list, on the side nearest the card you started from, with an arrowhead pointing straight up or straight down. The arrowhead means "scroll this column this way", not which issue blocks which.
• The label is a button. It reads ↑ #210 or ↓ #210. Click it and the column glides to the card over most of a second, eased in and out, then flashes it, so you can follow where you went. If the column alone can't bring the card into view, the page scrolls the rest of the way. Focus stays where it was. If your motion setting is off, or your system asks for reduced motion and you haven't overridden it, the column jumps straight there instead.
• The line waits for you. A line that ends at a column edge stays up for a moment after the pointer leaves the chip, and for as long as the pointer is on the label, so there is time to reach it. A line to a card already in view clears as before.
• Arrival. Once the card is in view, the line is redrawn to the card itself and stays for a moment, so both ends of the link are on screen together before it fades.

Cards off the edge of the whole board, and cards in a collapsed column, behave as before: an arrowhead at the board's edge, or one line to the column's strip.

In August we encrypted the most identifying things we hold, issue titles first, inside the database. That protected the fields. It left everything around them, the rest of the database, the cache, the files on the server, readable to anyone holding a copy of the disk.

That gap is now closed.

What changed

Your data is on an encrypted disk. The database, the cache, the local backups and the service's own secrets moved onto a separate encrypted volume.

The disk can't unlock itself. Its key isn't kept on the server. When the machine starts, it has to reach a key server that lives somewhere else, and only then does the disk open. A copied disk, a snapshot taken by the hosting provider, or a drive pulled from the rack is ciphertext on its own. We tested that the way it matters: with the key server out of reach, the disk stayed locked.

The old copies are gone. Moving data onto an encrypted disk does nothing for the copy it came from. The old database and cache files on the plain disk were deleted, and the space they took up on the disk was trimmed.

The encryption key was replaced. The key that encrypts titles and tokens inside the database was rotated during the move, and every encrypted value was re-encrypted under the new key and checked.

Two layers

Inside the encrypted disk, the application still encrypts the fields that say the most about your work: issue and merge request titles, milestone titles, branch names, the snapshots of linked issues, webhook deliveries waiting to be processed, and every access token. So reading those needs the disk's key and the application's key, and they are not kept in the same place. Off-site backups are encrypted before they leave the server, as they have been since August.

What this is not

This is encryption at rest. GitGumbo decrypts your data to draw your board, which is the point of a board, so it is not end-to-end encryption and we don't call it that. What it guarantees is narrower and still worth having: a copy of our storage, taken without the running service, tells nobody what your team is working on.

Four changes to how cards find their merge requests and their linked issues.

Stacked pull requests link on GitHub. GitHub only links a pull request to the issue it closes when the PR targets the default branch. Stack a second PR on the first and GitHub shows no link, so the card showed no PR either. GitGumbo now reads the closing keywords in the PR's title and description itself: close, closes, closed, fix, fixes, fixed, resolve, resolves or resolved, before #12 or a link to an issue in the same repository. Whatever GitHub links is kept; this adds to it. A bare #12 with no keyword still doesn't link, and neither does an issue in another repository.

GitLab MRs can close an issue by its URL. "Closes https://gitlab.com/group/project/-/issues/42" now links the MR to #42 on the card, the same as "Closes #42", as long as the URL points into the MR's own project. GitLab treats the two the same; now we do too. If your firm has turned on Bare mentions, a same-project issue URL counts as a mention as well.

Keywords inside code don't count. A Fixes #12 inside a fenced or indented code block, or in inline code, no longer links the MR, on either provider. That is how GitHub reads a pull request, and we checked it against GitHub before changing ours. A keyword in a quoted line (> Fixes #12) still links, because GitHub links those. On GitLab, where GitGumbo is the only thing reading these keywords, an MR whose only keyword sat in code drops off the card at its next sync.

Linked issues in other projects are named when you can read them. Until now a blocking or relates-to link into another project was listed as "Issue in another project", with no title and no link, because the board couldn't tell whether you may see it. Now, if that project is also monitored in the firm you're working in and your own access there lets you read the issue, the row shows its title, reference and a link, with In another project for its location. The check uses your access, not the account that syncs the board, so two members of the same firm can see the same row differently. Anyone else still sees "Issue in another project".

Blocking links say something can't move until something else does. Most links between issues say much less than that: these two are about the same thing. GitLab and GitHub both call that "relates to", and until now the board ignored it.

Cards now show it. A Relates to chip, with a link icon and the number of related issues, sits after the blocking chips. It is deliberately plain: it uses the board's neutral colours rather than red or violet, because a related issue doesn't hold anything up. Point at it or click it and the same panel as the blocking chips lists the related issues, rings the related cards on the board and draws lines to them. Those lines are dashed and muted, so they never read as a blocking link.

A few things worth knowing:

• Only real links. The chip shows the "relates to" links people made in GitLab or GitHub. GitGumbo never guesses a link from issues that mention each other.
• It works on GitLab Free. "Relates to" is the one link type GitLab Free lets you create, so it is the one link chip a GitLab Free project shows.
• GitHub too. GitHub made its "Relates to" link generally available at the end of September, and GitGumbo reads it the same way. Adding one on GitHub doesn't mark the issue as changed, so the ordinary background sync can't see it: GitGumbo picks it up in its hourly re-read of every open issue, or sooner if you choose Full Sync or the ↻ on the card. On GitLab, a new link arrives with the next background sync, every 5 minutes on Pro and every 15 minutes on Free.
• The first 10. GitGumbo reads up to 10 related issues per card. With more, the chip reads 10+.
• Other projects stay private. A related issue in a different project or repository is listed as "Issue in another project", without its title or a link, because GitGumbo can't check that you can see that project. The same now applies to blocking links.

The filter bar gains a Related toggle, which shows only cards with a "relates to" link. It is separate from Blocked/Blocking, and relates-to links never count toward that filter or the Blocking most sort.

If you'd rather not see them, Settings → Board display → Show 'Relates to' links on cards hides the chip, its lines and the Related toggle, for you only. GitGumbo keeps reading the links either way, so turning it back on shows them without waiting for a sync.

Someone says "can you look at 412?" and until now the board's search box could only help if 412 happened to be in a title. It searched titles and nothing else.

Type a number now and the board finds cards by number too. The match starts from the left, the way you'd type it, so 41 finds #41, #412 and #4100, but not #341. Keep typing and the list narrows.

Merge requests and pull requests count too, written the way your provider writes them:

• 412 finds issue #412, or any card with a linked merge request or pull request numbered 412.
• #412 finds issue #412. On GitHub it also finds pull request #412, because GitHub writes both the same way.
• !412 finds a linked merge request or pull request only, using GitLab's ! for merge requests.

The search box's hint shows the form for the board you're on: #issue or !MR on GitLab, #issue or #PR on GitHub.

As before, search looks at the cards the board has loaded and doesn't read labels or descriptions. A merge request drops off its card once it is merged or closed, so only open ones can be found this way.

The red Blocked and violet Blocking chips on a card open a panel that lists the linked issues. Knowing that #42 blocks this card was useful; finding #42 on a busy board was the next job, and the connector lines only help when the card is on screen.

Each row in the panel now says where that card is: In Review, In Progress, or whichever column holds it. It names the column even when your filters hide the card or its column is collapsed, so you know what to clear or expand. An issue the board hasn't loaded, such as one that closed a while ago, reads Not on this board. Screen readers hear the location with the link.

The filter bar's two toggles, Blocked and Blocking, are now one: Blocked/Blocking. It shows every card with either chip. With two separate toggles, choosing Blocked hid the very cards doing the blocking, so the chain you were trying to untangle was always half off screen. Now the blocker and the cards it holds up stay side by side. Like every filter, it is kept in the page address, so a link you share keeps it, and an older link that used either of the two old toggles turns on the new one.

One limit is GitLab's, not ours: GitLab only stores blocking links on its paid tiers, so on a GitLab Free project these chips, and the toggle, never appear.

Starting work on an issue usually means the same few steps on GitHub: make a branch, push something to it, open a pull request, and remember to write "Closes #12" so the two are linked. GitHub cards on GitGumbo can now do that for you.

Point at a card and choose the branch icon, Create pull request. A short confirmation names the branch it will create and the repository's default branch the pull request will merge into. Confirm, and the new pull request opens in a new tab. The card shows it as soon as the board next refreshes, without waiting for a sync.

It creates a draft. A pull request made before any work exists isn't ready for review, so it starts as a draft, and you mark it ready when it is, from the card or on GitHub. On a private repository whose GitHub plan has no draft pull requests, it opens as an ordinary one instead.

It adds one empty commit. GitHub won't open a pull request on a branch with no commits, so the branch gets a single empty placeholder commit. The confirmation says so before you click. That commit is unsigned, so a branch rule that requires signed commits will refuse it.

The pull request's description says "Closes #" and the issue number, so GitHub links the two, and merging it into the default branch closes the issue.

You need permission to push to the repository, and the account behind the board needs write access: a classic token needs the repo scope. If the board's token is read-only, the board says so rather than offering a button that would fail. The button isn't offered on an issue that already has an open pull request.

GitLab cards have had Create merge request since August. GitHub cards now have the same button.

Sometimes you don't know which guide holds the answer, or what the feature is called. The support page now has Ask the assistant: type a question the way you'd ask a colleague ("Why has my board stopped updating?") and get a short answer.

The assistant answers only from GitGumbo's own guides. Under each answer it lists the guide sections it drew on, so you can read the full detail, and check it. If your question isn't covered by the guides, it says so rather than guessing.

A few things worth knowing:

• It's on /support, for everyone, signed in or not. A quick check keeps bots out; most people never see it.
• Conversations are short, a handful of questions each, and there is a daily limit across the site. When the assistant is unavailable, the same box searches the guides instead.
• It is an AI model and can get things wrong. For anything about your account or a payment, Send us a message reaches a person.

GitGumbo now has proper help.

Thirteen guides cover the whole product, from getting started to columns, moving cards, sync, filters, firms and plans. They live at /docs, linked as Docs from the menu, and are open to everyone, signed in or not. Each one is written against the code it describes.

Docs search. The search box on /docs looks through the guides section by section, so a question like "WIP limit" takes you to the paragraph that answers it rather than the top of a long page.

A support page. /support brings it together: the guides, the search, and Send us a message. Pick a topic, write your question, and a person replies, usually within one working day.

Three smaller changes landed alongside the new guides.

The Sync menu says what each choice does

The Sync ▾ menu on a board offers Sync and Full Sync, and until now it was up to you to know the difference. Each choice now carries a short line underneath:

• Sync fetches what changed. It does nothing if the board synced in the last 30 seconds.
• Full Sync re-reads everything. It always runs, once a minute per project, and that minute is shared by everyone in your firm.

Both work on every plan.

Close a card that sits in a GitLab Status column

Cards in a GitLab Status column couldn't be closed from the board; you had to close them on GitLab. Now you can drop them on Closed, or pick Closed in the move menu, like any other card.

Closing also changes the issue's status, to your project's default closed status. That's Done, unless your group has customised its statuses. GitLab sets it, and GitGumbo reads it back straight after closing, so the card shows the new status on the board's next refresh.

Saved filters in Insights

Insights is coming with the Team plan. Team isn't on sale yet; you can join the waitlist on the Pricing page.

• Manage filters lists every saved filter you can use: your own and the ones shared with the team. You can rename or delete them there. Admins can also choose which shared filter is the team default.
• Naming a filter now happens in a field right next to the buttons, instead of a pop-up box. Enter saves and Escape cancels.

The Stats and Insights guide has the details.

A handful of changes, each small, that put more of your account in your own hands.

Leave a firm. In Settings → Firms, choose Leave next to any shared firm you don't own. Your own things in that firm, such as pins, saved filters and API tokens, are removed, and your seat is freed. Owners transfer ownership first.

Sign out of all devices. Settings → Sessions has Sign out of all devices, for the laptop you left signed in somewhere. It ends every session, including this one. API tokens are not affected.

A complete export. Settings → Data & Privacy → Export your data now includes what you hold in every firm you belong to, not only your personal one: preferences, saved filters, pins, card orders, automations, tokens (never the secret itself) and invites.

Members see their own tokens. Firm members now get an API access card listing their own API tokens. Adding, removing and pausing projects stays with owners and admins, and the page now says so rather than showing buttons that won't work.

Sign-in messages that explain. If you sign in with GitHub but your account was created with GitLab (or the other way round), GitGumbo now says so and points you to Settings → Linked Accounts, instead of returning you to the login page without a word.

Three changes to billing, all about doing what you'd expect.

Your trial's end date. During a trial, Billing & plan shows Trial ends and the date, where it used to say "Next billing date". If no card has been added by then, the firm simply goes back to Free. A firm that has already had its trial now sees Upgrade to Pro rather than an offer it can't take up.

Upgrade and your repositories come back. Moving to Free pauses syncing on repositories beyond its limit. When you upgrade again, those repositories now start syncing on their own. Ones somebody turned off by hand stay off.

Deleting a team refunds the rest. Deleting a team, or your account, with a paid subscription cancels it straight away and refunds the unused part of the current period to your card. You no longer pay for time you can't use.

Finishing a piece of work used to mean leaving the board to close the issue. Now the board does it.

Drop a card on Closed, or choose Closed from the card's Move this card menu, and the issue is closed on GitLab or GitHub. The Closed column now shows even while it's empty, so there is always somewhere to drop.

GitLab and GitHub differ

• GitLab: the labels behind the board's lists are removed when an issue is closed, as GitLab's own board does. Changed your mind? Drag the card out of Closed into a column. It's reopened and given that column's value.
• GitHub: labels are kept when an issue is closed. Closed GitHub cards can't be dragged back out; reopen the issue on GitHub and it returns to its column.

You need permission to close the issue on the provider. Everything else works on every plan.

If your team already arranges its work on a GitLab issue board, GitGumbo now shows that board. Every list becomes a column, in the same order, whether it is a label list, a status list, an assignee list or a milestone list. If a project has several boards, pick one from the board menu in the filter bar.

Moving a card does what moving it on GitLab's own board does:

• Into a label list: the label is swapped, or added if the card came from a different kind of list.
• Into an assignee list: that person is added to the issue.
• Into a milestone list: the milestone is set.
• Into a status list: the status is set.

To change the columns, change the lists on your GitLab board (Plan → Issue boards). GitGumbo follows. A project with no lists shows Open and Closed.

What to know

• GitLab only offers status, assignee and milestone lists on its Premium tier and above. On GitLab Free, your board is label lists.
• A card can now match two lists, say a label and an assignee. It shows in whichever sits furthest right, so occasionally it won't stay exactly where you dropped it. GitLab's board behaves the same way.
• On GitLab, the board is always a mirror. Renaming columns or grouping several labels into one column, as "Your columns" allows, is now for GitHub boards. WIP limits on a GitLab board come from each list's settings on GitLab.

This applies to GitLab projects on every GitGumbo plan.

GitLab issues are not all the same kind of thing. A task, an incident and a test case can sit side by side on one board, and until now their cards looked identical.

Cards for anything other than a plain issue now carry a small chip naming the type: Task, Incident or Test case, in GitLab's own wording.

The filter bar gains a type dropdown (All types by default), so you can narrow the board to, say, only incidents. Items synced before this change sit in a "No type yet" bucket until their next sync picks the type up.

GitLab projects, every plan.

Column automations let GitGumbo do the follow-up work when a card lands in a column: Mark draft MRs as ready, Assign to issue and Add MR reviewers. Until now, the column they fired on was worked out from its name. If your review column was called "In Review", it worked. If it was called "Code review" or "Waiting on QA", it didn't.

Now you pick it. In Settings → Column Automations, each recipe has a Column choice listing the columns on that project's board. That includes GitLab Status columns, so a board built on statuses can run automations too.

The nudge knows where you were

When you drag a card with a draft merge request into a column you haven't set up, the board asks: "Want GitGumbo to handle this for you?" Set this up now opens the automation settings for that project and that column, already selected, rather than leaving you to find them.

Column automations work on every plan, on GitLab and GitHub.

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 boards have it too, since 4 October: Create pull request on a GitHub card creates the branch and opens a draft pull request for the issue. GitHub won't open a pull request on a branch with no commits, so the branch gets one empty placeholder commit, and the confirmation says so before you click.

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.