libdex 1.2 is still in pre-alpha phase but it is also far enough along that it is worth talking about the direction: libdex is growing from a library of future and fiber helpers into a more complete concurrency toolkit.

The most important 1.2 theme is that applications can now describe not just what work should happen concurrently, but how that work should be bounded and owned. DexLimiter lets a workload run with a fixed concurrency budget, with dex_limiter_run() handling the common fiber case by acquiring a permit before work starts and releasing it after the fiber completes. For larger workflows, DexTaskGroup gives related futures a structured scope that can be closed, awaited, or cancelled as one unit.

That combination makes cleanup much easier to reason about when a workflow has many moving pieces. A loader can start many subtasks, keep only a useful number active at once, and return a single future representing the whole operation. If the window closes, the project changes, or the operation times out, the group gives the application one place to cleanly shut the work down.

static DexFuture *
load_many_files (GPtrArray *files)
{
  g_autoptr(DexTaskGroup) group = dex_task_group_new (0);
  g_autoptr(DexLimiter) limiter = dex_limiter_new (8);

  for (guint i = 0; i < files->len; i++)
    {
      GFile *file = g_ptr_array_index (files, i);

      dex_task_group_add (group,
                          dex_limiter_run (limiter,
                                           NULL,
                                           0,
                                           load_one_file,
                                           g_object_ref (file),
                                           g_object_unref));
    }

  return dex_future_with_timeout_seconds (dex_task_group_close (group), 10);
}

There is also a new DexThreadPool for the cases that are not naturally fiber-shaped. Fibers and schedulers are still the right fit for cooperative async work, but many applications need to integrate blocking libraries, database clients, filesystem helpers, or other foreign code. A fixed pool of reusable OS threads, dex_thread_pool_submit(), and asynchronous dex_thread_pool_close() give that integration story a bounded queue and an explicit shutdown path.

Deadlines are another practical piece of the same story. The new timeout wrappers, including dex_future_with_timeout_seconds() and dex_future_with_deadline(), turn time limits into ordinary future composition. Instead of open-coded timeout state spread across an application, a future can resolve normally, reject normally, or reject with DEX_ERROR_TIMED_OUT when the deadline wins.

On the I/O side, 1.2 continues filling in the operations that make responsiveness easier to preserve. dex_aio_open() and dex_aio_close() matter because even operations that look small can stall when they touch the kernel, storage, or network-backed filesystems. Keeping those calls in libdex's file-descriptor AIO model makes it easier to keep them off the UI thread, using io_uring where it is available and the fallback AIO backend elsewhere.

The broader GIO coverage is intentionally less surprising, but still important. More app launching, GFile, stream, socket, resolver, proxy, TLS, DTLS, permission, subprocess, and Unix-facing APIs now have future-first wrappers. That is the kind of coverage people should expect from libdex over time: not every wrapper needs a release headline, but each one reduces the pressure to leave the future model for common GNOME application work.

02 Jun 2026 3:14pm GMT

This first blog post marks the opening of the internationalization blog! The i18n team will use it to share news and projects on the current plans. Don't forget to subscribe!

The i18n team has seen some changes recently, at the beginning of 2026 and we thought it was necessary to publicly announce this change and introduce ourselves a bit.

Before all, we want to greet and deeply thank all internationalization coordinators that participated in the project so far and made GNOME what is is now. We are a global software community of volunteers, leading the free software ecosystem and are accessible in many languages. With this, we cover almost everyone on Earth. Thank you very much Andre, Alexandre, Claude, Daniel, Gábor, Gil, Mario, Piotr, Petr, Kjartan and all the others. Without you this wouldn't have been possible.

What is internationalization?

Internationalization, or i18n for short, is the act of ensuring software or documentation can be used in other languages, countries, and cultures. This means designing and developing applications in a way that removes barriers to localization, making it possible to adapt them without requiring significant engineering changes.

In practice, this involves separating user-facing text from the source code, so it can be translated easily, and ensuring that the software correctly handles different character sets and writing systems, including right-to-left scripts. It also means being mindful of cultural conventions such as date and time formats, number formatting, currencies, and units of measurement.

Internationalization goes beyond text. It includes accommodating differences in sorting rules (collation), keyboard input methods, plural forms, and even layout considerations, as translated text can vary significantly in length. Developers must also ensure that their software supports Unicode and uses libraries or frameworks that simplify handling these variations.

For the GNOME community, internationalization is a collaborative effort between developers, designers, and translators. By preparing software properly, the i18n team enables localization contributors to focus on producing high-quality translations, ensuring that GNOME is accessible and welcoming to users all around the world.

A new team

The team has reborn with new faces: Anders Jonsson, Rafael Fontenelle and Guillaume Bernard, respectively coordinators of the Swedish, Brazilian Portuguese and French team. Let's introduce ourselves a bit…

Rafael (@rafaelff) is coordinator of the GNOME Brazilian Portuguese Team for more than 13 years after a short but intense period of contribution as translator. Besides GNOME, he contributes to the translation of Python Docs, R language, Fedora, TranslationProject (GNU projects, etc.) and others. Also maintains some packages in Arch Linux's AUR.

Anders (@ajonsson) is coordinator of the GNOME Swedish Team for over 10 years, translator in the Swedish branch of the Translation Project, and a member of the GIMP Team with a focus on internationalization questions and testing.

Guillaume (@gbernard) is coordinator of the GNOME French Team since this year after 14 years of contributions, first as a translator, reviewer and after a few years, he has been involved in submitting team's translations. He is the maintainer of GNOME Damnes Lies, our translation platform since 2020. He took this responsibility after years of dedication from Claude. Thank you again for this mentorship!

02 Jun 2026 12:00pm GMT

Nine months ago, I had to field quite a few angry comments from folks who told me they intended to drop their GNOME Foundation memberships in the wake of confusing and opaque board behaviour. I say to you now what I told each of them back in September:

Stay and fight.

The GNOME Foundation saw a much needed - and long overdue - changing of the guard back in August of 2025. In the past 12 months, the Foundation has finally made the improvements it should have been making over the past decade:

• 2025-05-09 - GNOME's infra team had its first management review - it was spotless.
• 2025-05-16 - Foundation Reports begin in earnest as a first small step toward a transparent GNOME Foundation. We begin the hunt for a new Treasurer.
• 2025-05-23 - We started a Foundation Handbook to match handbook.gnome.org. (This has since migrated to a wiki.) We started moving all the Foundation's documents into a central location. Project management began at the Foundation for the first time ever.
• 2025-05-28 - The Foundation publicly acknowledged that attacks on our Matrix servers, using illegal images, constitute crimes.
• 2025-06-06 - Both donate.gnome.org and (later) fellowship.gnome.org are pitched and accepted by the board. We brought on Deepa Venkatraman as Treasurer. Bart Piotrowski set up vault.gnome.org for passwords.
• 2025-06-14 - Andrea Veri completed the transition to donated AWS resources for GNOME infra.
• 2025-06-20 - donate.gnome.org is released, thanks to the hard work of Bart, Sam Hewitt, and Jakub Steiner.
• 2025-06-26 - The "Donate Less" campaign begins, in anticipation of the outbound program that would become fellowship.gnome.org.
• 2025-07-05 - The concept of fellowship.gnome.org goes public. Work on the corresponding donate.gnome.org shell notification starts. We tightened fiscal controls. We added redundancy to all our financial, legal, and operational processes. We interviewed a pipeline of candidates and selected Ignacy Kuchciński to complete the work under the Digital Wellbeing grant.
• 2025-07-12 - We invited postmarketOS to the Advisory Board.
• 2025-07-21 - We started stabilizing the GNOME Foundation's finances for the long term by redefining the Board Reserve and taking a hard look at balancing year-on-year (annual recurring) revenue and expenses. We added the first-ever redundant signatories on bank accounts.
• 2025-08-08 - We created a shared online space for Advisory Board members to collaborate.
• 2025-09-05 - First corporate sponsor.
• 2025-09-12 - Deepa's budget process is "the best the Foundation has ever had," according to multiple directors.
• 2025-10-10 - Digital Wellbeing is delivered. The Foundation gets a much-needed credit card policy.
• 2025-10-24 - A new Finance Advisor arrives. (An important role at a 501c3.)
• 2025-11-28 - The budget is balanced. More importantly, the budget report contains the commitment to balancing recurring expenses and recurring revenue, continuously.
• 2025-12-19 - Deepa joins as a full director and remains Treasurer.
• 2026-01-09 - A new automated accounts payable and accounts receivable system is installed.
• 2026-03-20 - Financial reporting moves from quarterly to monthly.
• 2026-04-17 - The Fellowship Program begins! Users' donations come full-circle: a percentage of every donation now goes directly to developers.
• 2026-05-15 - Finances are on-target. The Foundation opens a position for Finance Director.
• 2026-05-29 - Four old finance platforms are retired as the finances of the Foundation are automated and simplified. The Foundation introduces a Concern Escalation Policy: if members feel that directors or staff are abusing their positions with policy violations, illegal activity, discrimination, or conflicted behaviour, they're provided the reassurance that they can blow the whistle without risk of retaliation.

That's a lot for one little nonprofit. But this is the beginning of GNOME Foundation 2.0, not the end. The work must continue and there is still plenty to be done.

If you let your membership expire in recent years, get it back. If you are thinking of leaving, don't. And if you are thinking of running for board elections, run.

The GNOME Foundation is the healthiest it's ever been. It's reducing costs and focusing on its actual mission: GNOME. The excellence demanded of GNOME hackers is now demanded of the Foundation, too. You can be a part of continuing that trajectory.

There has never been a more meaningful time to join the GNOME Foundation board.

01 Jun 2026 1:59am GMT

This article is also available in the B2B Services section on the gedit website.

Several business-to-business services are possible around gedit:

• Development of a new plugin.
• Development of a new text editor or Integrated Development Environment (IDE) based on the libgedit.
• Code maintenance.
• Training.
• Support.
• Creation of Long-Term Support (LTS) versions.
• Developer Experience (DX) guidance.
• […] Come with your own ideas to collaborate with the gedit project.

Target audience

• Operating System / Linux distributions: for your installed-by-default text editor.
• GTK-based desktop environments: to maintain a text editor or IDE, and to adhere to your Human Interface Guidelines (HIG).
• Scientific sector: to build developer tools.
• Education sector: to build easy-to-learn developer tools.
• New programming languages / development platforms: you're designing and implementing a new programming language, and you need developer tools for your users.
• Older programming languages users: you're a big organization and you have a lot of legacy code. You want better developer tools to be more productive.
• Markup or domain-specific languages: to better promote your language, you would like first-class support for it.

The libgedit shared libraries

gedit is not just a general-purpose text editor application, there is a "libgedit" underneath!

A lot of gedit features are implemented as re-usable code, as a set of shared libraries. So new apps - text editors and IDEs alike - can be built on top. There is an ongoing effort from the gedit project to make more code re-usable.

An example of an IDE based on the libgedit is Enter TeX.

The libgedit is in turn based on the very flexible GTK graphical toolkit.

GTK 3 or GTK 4

The libgedit currently targets GTK 3. If you want to develop with GTK 4, there is the GtkSourceView library (but it doesn't contain all the libgedit features). Another possibility is to first port the libgedit to GTK 4.

The plugin system

gedit has a powerful plugin system mechanism, to extend the application. You can leverage it for prototyping additional features, or as the final solution that requires less efforts than creating a new specialized text editor.

You can also combine the best of both approaches:

• First implement a feature that is based on libgedit.
• Then wrap your feature in a gedit plugin so it can readily be used.
• Finally, as an option, create a custom text editor app, re-using the same implementation of your feature(s), integrating everything well together.

Other developer tools

The text editor part is essential, it is the central feature of an IDE. But other developer tools can be developed as well.

For instance, Devhelp can be used for browsing and searching API documentation. Almost all its code is re-usable; like for gedit, there is a libdevhelp toolkit under the hood.

Advice to not start from scratch

A little advice: please don't create a new text editor or IDE from scratch, base your work on existing, high-level libraries like the libgedit. Even if it looks simple on paper, developing a feature-full text editor is a lot of work.

Use the libgedit from your preferred programming language

libgedit and GTK can be used from a wide range of programming languages, and the support for additional languages can be implemented too. This is thanks to GObject Introspection. See the list of language bindings for the GTK project.

Open-source or proprietary software

libgedit and GTK are licensed under the GNU Lesser General Public License (LGPL), which allows to develop proprietary software on top.

gedit plugins need to be distributed as free/libre software, under the GPL license.

Who to collaborate with

• Sébastien Wilmet, the current maintainer and main developer of gedit and libgedit.
• You? If you're or work for a consultancy company specialized in GNOME, GLib or GTK, and want to be part of this project, don't hesitate to get in touch!

30 May 2026 10:00am GMT

Update on what happened across the GNOME project in the week from May 22 to May 29.

GNOME Core Apps and Libraries

Maps ↗

Maps gives you quick access to maps all across the world.

mlundblad announces

Thanks to hard work by James Westman, Maps now supports dowloading map areas for offline use!

Document Viewer (Papers) ↗

View, search or annotate documents in many different formats.

lbaudin announces

Papers 50.2 and 49.7 were released this week with a (unusually high) number of bug fixes. Notably, several fractional scaling issues should be fixed thanks to the work of balooii, including both performance and display issues.

Libadwaita ↗

Building blocks for modern GNOME apps using GTK4.

Jamie (she/her) reports

The upcoming version of Libadwaita now supports binding properties to CSS Classes and vice versa, making it easier to dynamically toggle CSS classes on widgets. This will be available in the upcoming GNOME release.

GNOME Circle Apps and Libraries

Sophie (she/her) reports

We published a blog post with update from the Circle Committee. We are addressing our current review backlog, our new AI policy, new handling of submission issues, earlier reminders about outdated runtimes on Flathub, and new benefits for Circle projects.

Lőrinc Serfőző reports

A new version of Exercise Timer was released! This is a quality-of-life update for this simple app for high intensity interval training. Most notably, the training page has been updated with a custom progress indicator. Minor updates include an Undo option for deleted trainings and an update to the latest GNOME runtime. Get Exercise Timer from Flathub: https://flathub.org/en/apps/xyz.safeworlds.hiit

Resources ↗

Keep an eye on system resources

Sophie (she/her) says

Resources has been accepted into the GNOME Incubator, with the goal of eventually replacing the current System Monitor in GNOME Core. You can try the current development state via the nightly Flatpak or on GNOME OS.

If you find any issues or regressions compared to the current System Monitor app, please report them in the Resources issue tracker. The potential inclusion into Core is tracked under App Organization. Distributions are encouraged to package the app and report any issues they foresee with a possible transition to Resources.

Congrats and big thanks to nokyan for writing and maintaining this app!

Third Party Projects

Jan-Willem reports

This week I released Java-GI 1.0.0-RC1. As the version number suggests, this is the first step towards a "stable" release. With multiple cool apps already on Flathub, like Speed of Sound and Subsound, and several more in active development, I figured it's time for backward compatibility and API stability.

Notable improvements in this release are:

• Support for non-UTF8-encoded filenames
• Specialized exception types (deriving from GErrorException)
• Improved Windows support
• Bug fixes around memory management, class instantiation and nullability annotations.

Always wanted to build a GNOME app, using your Java (or other JVM language) skills? Give Java-GI a try!

lo reports

Nucleus version 3 is released! Nucleus is a periodic table app.

This update brings a theoretical indicator to Ununennium, as well as some updated properties for Ununennium. French and Italian translations were added and the app was updated to the GNOME 50 runtime as well.

Get it on Flathub: https://flathub.org/apps/page.codeberg.lo_vely.Nucleus

seja-arctic-fox says

I'm happy to annouce that VidCom 0.82 has just been released!

VidCom is a simple utility for archiving videos, written in C++, using ffmpeg for video compression. Major changes in this version include:

• Multiple stream and subtitle support, switching between mp4 and mkv containers as needed
• Faster seeking when Cut Feature is enabled
• Fix to correctly compute bitrate when Cut Feature is enabled
• Audio is now encoded in Archive mode as well. Previously it was just copied
• New cut widget and time setters
• UI rework to fit more into the GNOME ecosystem
• Switch to GNOME 50 Runtime
• Status pages for 'empty queue' and 'encoding' states
• Improved page for viewing results, which does not create a popup window anymore
• Popup messages changed to toasts
• Small UI desing adjustments; rounded thumbnail corners, better info distribution, formatting bugs
• UI refactor

VidCom is avaiable on Flathub and AUR. Source code can be viewed here

Anton Isaiev announces

RustConn Versions 0.15 Released

I want to thank everyone who opened a request or sponsored the project. All this time, the main features I shipped came from user requests. The most important ones: broadcast, a keyboard passthrough mode that disables the app shortcuts so they go straight to the remote desktop, Windows scripts, and a wizard for an easy start with predefined custom commands. I use all of this every day and it genuinely makes life simpler - which was the whole idea behind the project.

Homepage: https://github.com/totoshko88/RustConn Flathub: https://flathub.org/en/apps/io.github.totoshko88.RustConn

Solitaire ↗

Play Patience Games

Will Warner announces

Solitaire 50.2 is out!

Here is what's new:

• Added translations: Georgian (Ekaterine Papava), 'Chinese (China)' (lumingzh), Ukrainian (Yuri Chornoivan), Serbian (Марко Костић)
• Updated translations: Cornish (Flynn Peck), Slovenian (Martin S.), Basque (Asier Saratsua Garmendia)
• Updated the scores dialog
• Added an option to the preferences to set the seed for dealing
• Made unfinished games automatically save
• Fixed a bug where cards could be dragged from the foundations in Spider
• Made cards not get selected when dealt
• Increased the height of tableau in Klondike
• Added a 'Redeal Game' option to the new game dialog
• Made Tri-Peaks allow Ace + King card combinations

You can get Solitaire on Flathub

Gitte ↗

A simple Git GUI for GNOME

Christian reports

Gitte, a simple Git client for GNOME built with GTK4, libadwaita and Relm4, just got its 0.5.0 release! 🎉

The headline feature this time is commit and tag signing. Gitte now supports GPG, X.509 and SSH signing, validates signatures right in the commit log, and ships a dedicated "Signing status" window that walks you through setting everything up. Encrypted signing keys are handled via a new gitte-askpass helper, and every relevant dialog (commit, merge, revert, create tag, …) gets a per-action override switch so you can decide whether to sign on a case-by-case basis. The default respects the repository configuration.

On top of that, the commit message, revert and create tag dialogs were overhauled, dialogs now carry descriptive subtitles for better discoverability, and there's a new Ctrl+O / Cmd+O shortcut to open a repository. Under the hood Gitte moved to the new git2 API, switched from polling to IO-event-based refreshes, and gained a Cornish translation (thanks to Flynn Peck!).

Get it on Flathub, for macOS or have a look at the Code.

That's all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

29 May 2026 7:49pm GMT

Welcome to another update about everything that's been happening at the GNOME Foundation. As has become my custom, this post covers a two week period, this time from 18 May until today, 29 May. As usual the Foundation continues to be busy, with events, infra, governance, and accounting activities all happening simultaneously. Read on for more information!

Events

Linux App Summit (LAS) 2026 was held in Berlin over the 16-17 May weekend. I've heard quite a few reports now, and everyone seemed extremely positive about the event. Kristi wrote a nice summary if you want more details.

The GNOME Foundation had two team members on the ground helping with running the event, which we co-organize with KDE. I'd like to take this opportunity to give a big thank you to the event's sponsors: openSUSE, Tuxedo, Nextcould and Codethink. This event wouldn't be possible without your support.

In addition to LAS, work is continuing on arrangements for GUADEC 2026. The deadline for travel sponsorship applications has now passed, and the Travel Committee has met to decide who will be funded. Notifications will be going out soon.

Board Elections

The process is officially underway for this year's Board elections. Terms on our Board of Directors are two years in length, and each year half the board seats are open for election. This year we have five seats being contested.

The 2026 election has a slightly different schedule to previous years. In the past, there was no gap between the candidacy period, in which people can announce their intention to run, and the voting period. This meant that there was little opportunity for last-minute candidates to participate in discussion prior to voting taking place.

To address this, we've added a one week discussion period to the schedule, which will run between 8 and 15 June, between the candidacy and voting periods. This will hopefully give us opportunity to have more structured and inclusive debate amongst the candidates. We are still figuring out what that might look like, so if people have ideas or want to help, let me know in the comments.

GNOME Fellowship

We are currently in the very final stages of confirming and announcing the successful candidates for the inaugural round of the Foundation's Fellowship program. Expect an announcement very soon.

Got a Concern?

Last week we introduced a new policy for handling of concerns about the Foundation, which is now part of the project handbook.

The new policy covers how to report concerns about people who are working for the Foundation, either in a paid or voluntary capacity. It also covers more general concerns about the Foundation.

The main goals of the policy are to:

• have a documented reporting procedure for those who have concerns relating to the Foundation
• clarify how concerns will be responded to
• provide reassurance for those reporting concerns, including that concern reports are welcome, are taken seriously, and will never result in retaliation

We hope that this policy will make it clear how you can inform us of a concern if you have one. We also want to emphasise that we want to hear concerns, so we can address them. Please do use the new reporting procedure.

Finance/Accounting

Work has continued on the finance and accounting operation over the past two weeks. Highlights include:

• Our transition to a monthly rather than quarterly close reached a significant milestone this week, with the completion of our April finance reports within three weeks of the previous month end. This is probably the fastest ever turnaround for our finance operation, and is a huge win for us in being able to effectively manage our finances.
• Following input from the board, corrections have now been sent to the accountants for our audit and annual tax filing.
• Applications are still open for our Director of Finance and Operations part-time contract. Candidates have until 4 June to submit.
• Finally, as I mentioned in my last update, we are in the process of retiring a number of finance platforms as we consolidate and streamline our operation. This week saw another platform retired, which brings the total number of eliminated platforms to four.

Infrastructure

Our infrastructure experienced a DDoS attack last weekend, which Bart and Andrea have been dealing with. Thankfully it seems that services weren't too badly affected, and we've already improved our protection against similar attacks in the future.

Also on the infra side, Bart wasn't at LAS this year, but he did spend some time writing two great posts about Flathub's internals: How does Flathub even work? and Why are Flathub downloads so slow sometimes?. They're a fascinating read if you're interested in Flathub.

That's it from me! As always, thanks for reading, and see you in two weeks.

29 May 2026 4:41pm GMT

We want to share some updates and future plans from the GNOME Circle Committee with you. The Circle Committee is responsible for reviewing and accepting apps and other components into GNOME Circle as well as maintaining the review criteria.

The biggest issue for us, and for maintainers who submitted apps, has been the considerable backlog of unreviewed apps. There are cases where apps have been waiting for feedback for years. We are very sorry for those who have been affected by this. We are trying to finally address this issue now.

AI Policy

As a precaution, we have adopted the AI policy that already applies to GNOME Shell extensions. With the rise of low-quality machine-generated software, there is a risk that GNOME Circle could be overwhelmed by new submissions of this nature, further clogging the review queue.

This policy is a starting point, and for now, it will only be enforced on new submissions. We are open to receiving feedback on the AI policy from existing Circle maintainers. In a quick survey, 62% of Circle maintainers reported not using LLMs at all, 34% reported using them for small questions or snippets, and only 3% are taking larger parts of code from them. No maintainer selected the option for no longer writing code themselves.

Meanwhile, Flathub has also tightened their AI policy. Since GNOME Circle apps are usually expected to be published on Flathub, this policy indirectly applies as well.

Closing New Submissions

To make sure that we are focusing on submissions that haven't been addressed for a long time, we will stop accepting new submissions for now. We will reopen submissions when we have made a considerable dent in our backlog.

New Handling of Issues

This is mostly a technical detail, but from now on, we will close issues that are awaiting feedback from the maintainer. When providing an answer, maintainers should just reopen the issue. This gives us a better overview of which issues are awaiting further processing by us.

Early Reminder About the Use of Outdated SDKs

Every GNOME release cycle, we spend a considerable amount of time on getting GNOME Circle apps to update their SDK on Flathub before the SDK becomes unmaintained. To avoid this in the future, we will try something new: We will remind maintainers much earlier that they are using an outdated SDK - months before it reaches EOL, rather than just a few weeks. This means apps using the GNOME 49 SDK will soon be part of an automatically generated reminder issue. To get the reminder, please make sure that you have provided a GNOME GitLab account in your project's .doap file.

Growing Benefits

We are steadily growing the benefits for GNOME Circle apps and their maintainers. Among the benefits that were added are:

• Having a student work on your project for Google Summer of Code or Outreachy.
• Hosting your help pages on help.gnome.org.
• Getting a tag for your project on GNOME's Discourse.

Of course, all contributors and maintainers of GNOME Circle projects are still eligible for GNOME Foundation membership. You can check our full list of benefits.

Call for Reviewers

We are in constant need of more reviewers in the Circle Committee. If you have already reached out to us, and we haven't gotten back to you, please give it another shot. You can find us in #circle:gnome.org.

29 May 2026 2:15pm GMT

Here are the noteworthy news about the gedit and Enter TeX text editors. (Some sections are a bit technical).

A single package for gedit and its core plugins

Before, users needed to remember to install the gedit-plugins package in order to benefit from additional plugins such as Word Completion or Bookmarks.

Now, all core - or "official" - plugins are part of the main gedit module. So, Word Completion, Bookmarks and others have been copied into the gedit module, and gedit-plugins is now empty/archived.

Note that there are also third-party plugins which are available in other repositories.

New version on the Microsoft Store

gedit 50.0 is now also available on Windows.

The re-implementation of document loading continues

It's now a recurrent topic. Progress has been made, but more work is necessary to fully replace the GtkSourceFileLoader internals.

This time, here is a general description of the methodologies used along with the current state of affairs, without entering into too much technical details. If you're an experienced developer, it'll most probably ring a bell to you :-)

The typical "divide and conquer" methodology is followed: the problem is divided into several smaller ones. The sub-problems are solved individually, providing utility functions and small classes. Then things are built on top, with several layers, gradually solving bigger and bigger problems.

It all looks nice, except that an iterative process is also needed, to revise the solutions already built because of unforeseen problems (it happens all the time in computer science).

The current progress status is that some utilities need to be reworked in order to be a better fit for the above components, and also to fix a couple of unforeseen problems. Thankfully it's not a "back to the drawing board" situation, as the utilities that lie at the bottom layers don't need any change.

For the curious reader, here are the two unforeseen problems encountered:

• iconv() can output nul bytes even for UTF-8 as the target charset. Embedded nuls are not valid UTF-8 according to g_utf8_validate(). So an additional pass of validation is necessary, to escape invalid UTF-8 bytes.

• With the new implementation, at most two copies of the whole file content needs to be present in memory. I stumbled across a corner case where three copies would be necessary, so it needs to be fixed. The three copies were: (1) the content containing a single chunk (or at least a big chunk) of invalid bytes, (2) the invalid chunk escaped, and (3) the content as inserted into the GtkTextBuffer.

  It's just a matter of escaping the invalid bytes directly / at a different place.

  (Note that this is a concern only for the work-in-progress branch; current stable versions of gedit doesn't suffer from that issue).

Enter TeX goodness

The Projects feature has been re-implemented in a better way (mostly under-the-hood changes).

The module is again on GNOME Damned Lies, so there are many translation updates. Thank you, all translators around the globe! In the past I contributed to the French translation, and I directly saw that GNOME translation teams do very high quality work. So, thanks again :) !

Other stuff

As usual there are some other work items fixed or where progress has been made. Among others:

• The comment/uncomment actions have been fine-tuned.
• A prototype has been created in order to improve the main "sandwich" menu in gedit.

Code re-use and Business-to-Business opportunities

There is a lot of potential with the libgedit modules (or also with GtkSourceView for GTK 4), to grow the project into something like the GStreamer multimedia project (but at a smaller scale) where there is a lot of B2B activity with consultancy companies helping to create new products for other businesses.

Especially with libgedit-tepl, the name "Text editor product line" means that it's possible to create other text editors or IDEs products (more easily).

An example that I have in mind is Arduino and its specialized IDE. But there are new programming languages or development platforms that pop up regularly, so there are opportunities to collaborate with them and develop great developer tools for them.

I'll talk about it more in the future, but if you read this and are interested to develop such a business model for gedit and/or GtkSourceView, talk to me!

29 May 2026 10:00am GMT

Ongoing Work

Back in March, I started to tackle this MR for GNOME Crosswords. It allowed me to learn a lot about navigating the codebase, adhere to naming conventions, and collaborating with others involved in Crosswords.

Crosswords Editor features a section for users to input metadata, such as author name, puzzle URL, and date. Originally, the MR was to convert and store the user's manually typed date to ISO8601. This means storing the entered date in the form YYYY-MM-DD, while the user just needs to type in a date using the GDate struct.

Upon code review, the scope expanded to move from manual typing to selecting a date on a drop-down GTK calendar widget. I was able to implement this concept by following the architecture of an existing widget (edit-shapebg.c/h/blp) which placed shapes on the crossword puzzle. Then I connected the new calendar widget to the metadata so the chosen date from the now drop-down calendar will be stored in ISO8601 format yet display respective to the locale of the person using g_date_strftime.

Project Start

With the start of GSoC, I have spent a lot of time this week reading, white-boarding, and began setting up some structure to adding vocab-style crosswords to the libipuz library.

The basic constraints and workflow that I mapped are:

• A user can input up to 30 words (strings), with a 25 character capacity.
• Upon hitting enter or a button to generate, a Depth-First Search (DFS) algorithm starts to piece the words together on a blank grid. The algorithm can backtrack to tear apart words and rearrange them until a valid graph is formed
  • I'm going with DFS at the moment to prioritize the longest-to-shortest word seeding the graph in order to increase possibilities of connections
• Every time the user generates the graph, it will be treated like its own isolated creation, recalculating the layout from scratch to allow for cleaner undo/redo states and easier addition/deletion of words
• I don't want words being placed right next to each other unless it was intentional for a 2+ word answer, which each word would be separated by thick lines
  • Words should only connect through intersections
    • The frontend does not mutate the grid but will be able to pass actions to the backend and return a new state
    • For instance: say a user starts off their grid by typing "CAT" and then "DOG." These words don't have common characters, so they cannot be connected. However, instead of erasing the user's desire to incorporate "DOG," the string gets tucked away and saved in a GArray

• Now our user types and enters "CADET." The UI takes our list and passes it to the algorithm to start chewing on and deal onto the board anew. This time, allowing for "CAT," "DOG," and "CADET" to appear, without the user having to retype "DOG"

I went back and forth with myself on how to represent the puzzle's state in memory and disk. To write a custom GObject, or not.

The Argument Against: Standard IpuzCrossword objects have a handle on grids and JSON saving, and one could write a new function that takes an array of strings and return a standard IpuzCrossword.

The Argument For: Revisiting the "CAT," "DOG," and "CADET" conundrum; say an educator is creating a puzzle for his/her/their class, and they have just one word out of 20 that don't connect to current existing possibilities of intersecting words. If they save their puzzle, it transforms to a standard IpuzCrossword, and the floating word are permanently abandoned.

At the current moment, I want the puzzle to be its own vocab-style workspace. Therefore this would allow for the floating word to instead sit in the sidebar and wait for further instruction for a future inserted word that works, or to get deleted.

Of course, as I gain more insight about the library, states, and optimization within the codebase, this approach is subject to refinement.

29 May 2026 12:28am GMT

With the release of 4.23.1, GTK's renderer will come with a new feature that we've called snapping.

How does it work?

Snapping is enabled by calling gtk_snapshot_set_snap(). If enabled, it will slightly adjust the placement of rectangles when drawing so that they align with the pixel grid and don't cover half a pixel.

Content drawn with GTK is scaled automatically by the desktop's scale factor. But with the arrival of native fractional scaling, it is no longer possible to know if content is aligned to the pixel grid.

While that is usually not a problem, there are a few cases where it is:

Sprite grids

Gameeky is a learning game that plays on a grid. Unfortunately, on a fractionally scaled machine, it can end up looking like this:

Once those sprites are snapped to the pixel grid by rounding to the nearest pixel, the same image looks like this

Sharp images

Often Applications want to display images in a way that matches the pixels of the image 1:1 with pixels of the monitor. This is a challenge on a fractionally scaled display. Not only is it important to get the scale factor right, it's also important to align the pixels correctly, or they will appear slightly blurry.

The use case is not just image viewers that want to offer a 1:1 zoom factor, but all applications that redirect drawing, from game emulators to viewers like Boxes or Connections.

Hardware optimizations

And finally, there are optimizations like graphics offload that rely on content being aligned to the pixel grid or the hardware cannot optimize them. So it is important to snap content to the pixel grid for those cases.

Why don't we just always snap to the grid?

There is one big problem with automatic snapping: smoothness. Because snapping only works on full pixels, doing slow animations causes content to jump from one pixel to the next. And that causes jitter.

The main situation where one can see this is smooth scrolling, like in this example:

Summary

The next GTK release will offer a new way to tame the effects of fractional scaling. Please try it out and let us know how it works!

28 May 2026 1:41am GMT

While working on my GSoC project (rewriting the Pitivi timeline in Rust), I ran into an issue getting precise UI ticks that map to the absolute nanosecond timestamps of the video frames. Initially I hardcoded NTSC fractional math (24000/1001) to calculate the boundaries of frames.

This led to issues with truncated timestamps, and had a glaring issue with other framerates (like 30fps). I needed a more robust solution that could handle any framerate and provide accurate tick positions.

I assumed that I could extract the framerate directly from ges::Timeline, however there is no direct getter in the Rust bindings. After some digging, I discovered that the framerate is actually stored in the gst::Caps of the timeline's video stream as a gst::Fraction.

My Approach

The steps I used:

• Enumerate the timeline tracks (timeline.tracks())
• Filter for the video track (checking ges::TrackType::VIDEO)
• Read the track's restriction_caps
• Extract the gst::Fraction

My helper

I wrote a helper function to extract the framerate from the timeline:

pub fn get_fps(&self, timeline: &ges::Timeline) -> Option<(i128, i128)> {
    timeline
        .tracks()
        .into_iter()
        .find(|track| track.track_type().contains(ges::TrackType::VIDEO))
        .and_then(|track| {
            let caps = track.restriction_caps().or_else(|| track.caps())?;
            let structure = caps.structure(0)?;
            let fps = structure.get::<gst::Fraction>("framerate").ok()?;

            // Extract the safe numerator and denominator
            Some((fps.numer() as i128, fps.denom() as i128))
        })
}

// ... inside the timeline injection logic:
if let Some((fps_num, fps_denom)) = self.get_fps(timeline) {
    self.fps_num.set(fps_num.max(1) as i32);
    self.fps_denom.set(fps_denom.max(1) as i32);
} else {
    // Default to 23.976 if we can't find a valid framerate caps
    self.fps_num.set(24_000);
    self.fps_denom.set(1_001);
}

I make some assumptions here, such as only one video track existing, and that the framerate is always present in the caps. This solution made the tick spacing and labels line up with the timeline's actual frame boundaries at any framerate.

27 May 2026 12:00am GMT

I do not always want to know what time it is. This is a slightly awkward position for someone who keeps making clocks, but there we are. Quite often the useful answer is not 17:42. It is "quarter to six", "nearly lunch" or "you should probably start thinking about leaving". The precise time is useful when catching trains, baking things and joining calls; the rest of the time it can be a bit much.

So I have been working on fuzzy time for a while. The first version I made was for the Pebble, which remains one of those devices that makes later technology feel slightly ashamed of itself. A small always-on screen, good battery life, physical buttons and just enough personality. It's not tokyoflash after all.

The current versions are Fuzzy Time GB, a Wear OS watch face, and Fuzzy Clock GB, a GNOME Shell extension.

The Android version is quite a funny object internally. It is a Watch Face Format v2 face, so the APK has no app code:

android:hasCode="false"

The face itself is declarative XML. Since writing thirty-six thousand lines of watch face XML by hand would be a cry for help, there is a generator which writes the cases out from the same fuzzy time rules. For every hour and every five-minute bucket it emits the condition, text and separate interactive and ambient versions.

That sounds excessive until you look at the details; and then it still sounds excessive. There are lots of pernickety things that give this the correct GB locale to my ears. "Five Past Midnight" is a real phrase. 23:58 should say "Midnight", and if the date is visible it should be tomorrow's date. 11:58 should say "Noon". "O'Clock" wants different spacing and weight from "Twenty-five To". Ambient mode wants smaller, quieter text. A round watch face leaves less room than you think it does. The watch face has a few small choices rather than a settings cathedral: warm white, cool white, soft green, dim amber; system font or Arvo; optional radial complication slots above and below the text. The range complications are deliberately arcs around the edge rather than little widgets in the middle. They can show useful things, but they should not make the face stop being mostly words and calm black space.

The GNOME version is the same idea on a different surface. It finds the existing clock label, listens to the same wall clock, respects the existing "show date" and "show weekday" settings, and changes the text. I have wanted to build something like this for years, partly because of Emmanuele Bassi's word clock extension. That extension was great, but not quite the thing I wanted, so eventually I got around to making my own.

One of the few design decisions left that I helped on in main GNOME (which is much better now) is that the shutdown and logout dialogue only updates its timing every so often. It could update every second; the computer is quite capable of counting. But it's much more pleasant when the number doesn't twitch constantly while you are trying to decide whether you meant to press the button.

You can build both projects from source. I may choose to distribute them in a more structured fashion in future. The Android one is a minimal Wear OS watch face, and the GNOME one is a normal Shell extension that currently supports GNOME Shell 45 to 50.

26 May 2026 8:57pm GMT

About Me

Hello Everyone! I am Shivam, I am currently pursing my engineering in Electronics. I have been selected for GSoC 2026 for the port of GNOME-Gitg from GTK 3 to GTK 4. I am starting this blog in order to document my journey of porting Gitg. I have been contributing in GNOME from several months and in awe with the supportive and helpful nature of the community.

Project

As many of you probably know, Gitg is still using GTK3, which means it misses out on a lot of the improvements and features that came with GTK4. The main goal of this project is to port Gitg from GTK3 to GTK4 and then gradually modernize the application.

The scope of the project itself is quite large, and that's honestly one of the most exciting parts for me. Working on this port will help me understand the application interacts with different libraries and components behind the scenes.

At the same time, I hope that this work will help the new contributors like me easier to get started contributing to the various GNOME projects

Conclusive Goal

The final goal of this project is to get Gitg building and running completely with GTK4 dependencies. At the moment, the application still fails to compile, which is expected since many GTK3 APIs are still present throughout the codebase.A separate GTK4 branch already exists where parts of the migration work have been started, and several components have already been adapted to GTK4. This project will continue building on top of that existing effort and gradually move the remaining parts of the application to the newer toolkit.

I would also like to sincerely thank the contributor(s) who have worked on the GTK4 porting work earlier. Their efforts created the foundation for this project, and I'll be continuing from the work they have already done.

Thank You For Reading!

PS:- I would also like to thank Alberto Fanjul for mentoring me in this project and Felipe Borges for this time and support.

25 May 2026 5:32pm GMT

I made another weird side project while unemployed. In fact I've wanted it for a while but once I learned that "Rebonjour" is the word for "hello again" I just had to finish the library.

librebonjour is an asynchronous DNS-SD and mDNS client library for GLib applications. Or, more practically, it is a small GObject API over the two local service-discovery providers you are likely to find on a Linux system: Avahi and systemd-resolved.

It does not link against either of them. It only talks to them over D-Bus.

The reason for that is mostly boring, which is usually where the useful things are. Applications should not need to care if a machine has Avahi running, or if it is using systemd-resolved for mDNS. They should be able to discover a service, resolve it, maybe advertise something, and get on with whatever they were actually trying to do.

So RebonjourClient selects a backend internally. If org.freedesktop.Avahi is available on the system bus, it uses Avahi. If not, it falls back to systemd-resolved's org.freedesktop.resolve1 API. If neither is around, availability checks fail like you would expect.

The public API stays the same either way.

What It Does

There are three common things I wanted to make pleasant.

First, one-shot discovery. Ask for the service types in local, ask for instances of something like _ipp._tcp, then resolve one of those instances into addresses and TXT metadata.

Second, browser-style discovery. A RebonjourBrowser owns a stable GListModel of RebonjourService objects. That fits nicely into GTK code because the model object can stay the same while the contents change underneath it.

Third, registration. You can describe a local service with RebonjourServiceDescription, register it, and keep the returned RebonjourRegistration alive for as long as the service should be advertised.

Resolving a service gives you a RebonjourResolvedService. That contains the SRV result, TXT data, priority, weight, and a model of RebonjourEndpoint objects. The endpoints hold the GSocketAddress you would actually use to connect.

Why Two Backends

Avahi is the nicer backend for browsing. Its D-Bus API gives you long-lived browser objects and emits signals when services appear and disappear. That maps very naturally to GListModel changes.

systemd-resolved is different. It has useful DNS-SD and mDNS operations over D-Bus, but the browsing side is lookup-based. That means you can ask what is there, but you do not get the same live add/remove signal stream that Avahi provides.

I did not want applications to have to care about that distinction unless they really want to. So the browser has auto-refresh and refresh-interval properties. With Avahi, auto-refresh is effectively harmless because the model is already live. With systemd-resolved, it starts an internal refresh loop and updates the model for you.

It is not magic. It is just putting the backend-shaped unpleasantness in one place so application code can stay boring.

Asynchronous with libdex

The whole thing is built on libdex. Anything that might touch D-Bus or the network returns a DexFuture.

That means construction, availability checks, service-type lookup, instance lookup, resolving, registration, browser refresh, and unregistering are all future-based. If you are already writing fiber-style code with libdex, the API fits into that directly:

[code language="c"]
g_autoptr(RebonjourClient) client = NULL;
g_autoptr(GListModel) services = NULL;
g_autoptr(GError) error = NULL;

if (!(client = dex_await_object (rebonjour_client_new (), &error)))
g_error ("%s", error->message);

services = dex_await_object (rebonjour_client_lookup_instances (client,
0,
"_ipp._tcp",
NULL,
REBONJOUR_LOOKUP_FLAGS_NONE),
&error);
[/code]

The 0 there means any interface. Passing NULL for the domain uses local. The common case should not require looking up interface indexes which I'm pretty sure most people reading this have never even done before.

Advertising

Advertising is where things get more system-policy-oriented.

With Avahi, registration goes through Avahi's D-Bus API. With systemd-resolved, registration uses RegisterService and UnregisterService, which are polkit-protected. Also, resolved needs full mDNS enabled with MulticastDNS=yes; MulticastDNS=resolve is enough to browse and resolve, but not enough to respond as a service.

So librebonjour can expose one API for registration, but it cannot make host policy disappear. Applications still need to handle authorization failure, missing mDNS responder support, sandbox boundaries, or whatever policy the system administrator has decided is appropriate.

That seems like the right way to demarcate things. The library should hide the provider mechanics, not the permissions of the platform.

Why

Mostly because I wanted this to exist.

DNS-SD is handy. Local-network service discovery is still useful. But using it from a GLib application means either caring too much about the provider or writing just enough glue that every application gets to have its own slightly different version of the same code.

And even worse is having to bundle things to build projects like Avahi for Flatpak when you only use the library which calls into D-Bus anyway.

This is not a grand platform initiative. It is not something I am employed to maintain. So you know, use wisely.

23 May 2026 4:18pm GMT

Update on what happened across the GNOME project in the week from May 15 to May 22.

Third Party Projects

Alexander Vanhee reports

Last Saturday, Bazaar was updated to 0.8.0 with the ability to install .flatpak bundles. We created a fancy new dialog so people can better understand what happens when they install one. We also added the ability to remove app caches directly from within the sizes dialog and reworked the app install animations.

Feel free to leave your feedback on the GitHub repo!

Luiggi R. Cardoso says

Draft v1.3 has been released!

You know those text snippets you need to save, that quick idea you want to write down, or a link you need to hold onto but don't want to open a heavy app for? This is Draft.

This new version brings:

• Estonian and Brazilian Portuguese Translations (thanks to our community!).
• Keyboard shortcuts for formatting options.
• Under-the-hood performance fixes and minimal spellchecking support.

Download it on Flathub | Contribute on GitLab | Help with Translations

Bilal Elmoussaoui reports

I have released a new version of gobject-linter. The release includes:

• Parse custom types using g_type_register_static directly
• Add a new unused vfuncs rule
• Add a new missing_g_begin_decls rule
• Generate fixes for g_object_virtual_methods_chain_up, missing_autoptr_cleanup
• gi_missing_since rule now validates that enum members don't include inlined Since: annotations
• Improvements to various existing rules

francescocaracciolo says

Newelle 1.4.0 Released! Newelle (AI Assistant and Agent for Gnome) has received a new major update!

🔗 Added Interfaces: alternative way external applications can interact with Newelle! Featuring Telegram support, APIs, WebUI and more!

👷 Support for directly download pre-compiled binaries for llama.cpp instead of compiling

🔐 Better Command permissions

💬 Better Prompt Editing

📝 Better Font rendering and customization

Get it on Flathub: https://flathub.org/it/apps/io.github.qwersyk.Newelle

Wladimir Palant reports

Gnome Commander 2.0 has been released! Many changes:

• Rewritten in Rust, with better performance and stability.
• Added embedded terminal to display output of commands run in Gnome Commander.
• Redesigned Quick Search can now be used to filter the file list as well.
• Far better search performance and many more improvements to the Search dialog.
• Consistent handling of file encodings in the internal viewer along with lots of other improvements.
• Improved accessibility of the application, screen readers should be able to recognize the context everywhere now.
• More tab state is being restored on restart - selected file, column sizes and ordering, hidden columns.
• Tons of fixed bugs and more.

Anil reports

Codd 0.5.0 has been released!

Since the first Flathub release, several new features and improvements have been added:

• Secure password storage using the system keyring
• SQL script generation for tables
• A Table Inspector for inspecting columns, data types, defaults, constraints, indexes, foreign keys and triggers
• Additional table action options

Spanish translations have also been added recently, thanks to fvtronics.

Codd is a lightweight PostgreSQL client for GNOME, available on Flathub. Feedback, bug reports, and feature ideas from PostgreSQL users are very welcome.

Get it on Flathub or check out the source code.

Gitte ↗

A simple Git GUI for GNOME

Christian announces

🎉 Gitte 0.4.0 released!

Gitte is a GTK4/libadwaita Git interface for the GNOME desktop, written in Rust.

This version introduces a mainline concept: you can now mark a branch as your project's mainline and use it as a reference for merged-checks, filtering, and a brand-new "Sync with mainline" action that rebases your branch and fast-forwards it in one step. The commit log also gained a filter to only show commits not yet in the mainline.

Working with changes got more flexible: you can now revert commits straight from Gitte, partially stage untracked files, toggle an additive selection mode in the changed files list, and ignore whitespace in diffs. Staging and unstaging are now available via context menu, Enter, and double-click, and you can create a branch directly from any commit in the log.

The UI received a lot of polish. The push and pull dialogs are now visually distinguishable and show their targets in tooltips, "ahead/behind" is rendered as text instead of arrows, popovers no longer claim unnecessary width, and several diff styling glitches are gone. Checking out a branch now creates a detached HEAD, with switching as a separate, explicit action.

This release also brings a long list of fixes around macOS shutdown and keyboard shortcuts, keyboard navigation, files without trailing newlines, now respects fetch.prune = true in the pull dialog, and various small papercuts.

Get it on Flathub, for macOS or have a look at the Code.

Fractal ↗

Matrix messaging app for GNOME written in Rust.

Kévin Commaille reports

Here comes Fractal 14.rc. This release candidate comes with a fair amount of quality of life improvements:

• The sidebar room filter has been improved: Enter goes to first room result, and there's an empty state when no results match the term.
• The performance of the room list has also been improved, it should be mostly noticeable for accounts that have joined a lot of rooms.
• Informative events (Unable to decrypt, server notices…) are now styled differently to reflect their special nature and differentiate them from regular text messages that anyone can send.
• Calls are rendered in the timeline and incoming calls trigger a notification. We still don't support calls, but at least now you know when someone is calling and can open another client to answer.

As usual, this release includes other improvements, fixes and new translations thanks to all our contributors, and our upstream projects.

It is available to install via Flathub Beta, see the instructions in our README.

As the version implies, it should be mostly stable and we expect to only include minor improvements until the release of Fractal 14.

If you want to join the fun, you can try to fix one of our newcomers issues. We are always looking for new contributors!

Miscellaneous

Damned Lies ↗

The internal application to manage localization of GNOME & friends modules

Guillaume Bernard says

GNOME Damned Lies has received a few improvements this week! Focusing on the issues identified for the next GNOME 51 release, we implemented the auto-closing feature for translations pushed through a merge request. This way, a background job regularly checks the status of the merge request (GitLab instances and Github.com are supported) to auto-close workflows.

We also updated the look and feel of the vertimus workflows to use more native Boostrap base style and removed the custom CSS that was used to render the action history, easing the maintenance.

In addition to that, we added support for Codeberg.org projects. Only direct pushes are supported at this time, because we need to implement the plugin to open/check merge requests on Forgejo software. We are on our way to also support Freedesktop's GitLab instance soon.

That's all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

22 May 2026 7:31pm GMT

I have a server at home. It runs a Kubernetes cluster and a few services. I want to expose them to the Internet, so I can e.g. share public links from my Nextcloud, or synchronize my Kobo reader with Grimmory. But I don't want to expose my home IP to the world, and I want to have some reasonable protection against unsophisticated DoS attacks.

I realized that I can achieve that with a cheap VPS that acts as a front, HAProxy, and Wireguard.

I rented a tiny VPS for €4/month at Infrawire (1 vCPU, 2 GB RAM, 25 GB NVMe). I installed a Debian 13 on it, because I want that front server to be as stable and low maintenance as possible, and installed the Debian-packaged HAProxy onto it. I also installed Wireguard. The VPS has a publicly accessible IP, so it will be my Wireguard server: my server at home can reach the VPS to establish a tunnel, the opposite is not true.

On my k3s node, I've installed Wireguard as well. I configured Wireguard on the VPS and my k3s node to establish a tunnel between the two. I've also bound the sshd on my VPS to the wireguard address. Infrawire offers a console so I can unstick myself if I locked me out of my own server (e.g. by misconfiguring Wireguard on any side, or if my server at home had any failure).

I pointed all my DNS records to the VPS. The HAProxy is a "dumb" tcp forwarder, so I can keep operating like before on my cluster. In particular, HAProxy doesn't do TLS termination. My certificates are fetched on my cluster by cert-manager like before, using the http-01 challenge and Let's Encrypt. I could also move to dns-01 challenges, but http-01 just works and lets me switch to a registrar without an API if need be.

That way, I don't need a fixed IP at home, and I don't have to do any port-forwarding from my home router to my k3s cluster. Even better: the VPS has an anti-DDoS protection included, and I can also configure HAProxy to refuse too many connections from a same IP, I can make it close TCP connections that take too long to establish, and more. If my VPS gets hammered, I can still access my services from within my home network.

22 May 2026 4:00pm GMT