Google Summer of Code 2026 has been one of my biggest experiences in open source so far.

This summer, I had the opportunity to work with Neutralinojs as a GSoC contributor and build neutralinojs-builder, a CLI plugin for generating platform-specific installers for Neutralinojs applications.

The goal of the project was to make the journey from building a Neutralinojs application to distributing it much simpler. Instead of developers having to manually work with different packaging tools and platform-specific formats, the builder provides a unified interface through the neu CLI.

This was a collaborative project, and I worked closely with Subhash and mentors throughout the development. We built @neutralinojs-contrib/builder from scratch and divided the work across the different parts of the project.

The project was developed incrementally through multiple pull requests, with each part of the implementation reviewed and improved as we worked through the different stages of the project.

2. My GSoC Journey

I first came across Neutralinojs in mid-2025 while working on a college project where I needed to build a desktop user interface. While exploring different options, I discovered Neutralinojs and was really interested in how easily it allowed developers to build desktop applications using familiar web technologies like HTML, CSS, and JavaScript. The lightweight approach and simplicity of the framework immediately caught my attention, and I started exploring the project further.

As I became more familiar with the project, I started contributing as an early contributor and gradually became more involved with the Neutralinojs community. My experience with C++ and modern C++ also helped me a lot during this process. Since Neutralinojs has a native codebase, having a strong understanding of C++ made it much easier for me to navigate the codebase, understand how different components worked, and start contributing to the project.

Over time, I also got the opportunity to interact with the Neutralinojs mentors and community members through Discord. These interactions helped me understand the project better, discuss ideas, get feedback on my contributions, and become more comfortable working within an open-source community. What initially started as discovering a framework for a college project gradually turned into a much deeper involvement with the project and eventually led me to work on neutralinojs-builder as part of Google Summer of Code 2026.

3. Understanding the Problem

Neutralinojs already provides the neu build command, which builds an application and produces the platform-specific binary along with its required resources. However, building an application is only one part of the process. Once the application is built, developers still need to package those files into something that can actually be distributed to users, such as a .deb, .AppImage, .exe, or .dmg.

The problem is that each platform has its own packaging workflow and tools. Linux requires tools such as dpkg-deb or appimagetool, Windows uses NSIS and makensis, while macOS requires creating an application bundle and generating a DMG. These workflows have different structures, configuration requirements, and failure cases, making the packaging process difficult to handle consistently and automate.

The solution was therefore designed as a plugin for the neu CLI rather than as part of its core. Packaging introduces platform-specific tools and dependencies, which would make the core CLI larger and more difficult to maintain. By keeping the functionality in a separate plugin, neutralinojs-builder can provide the required packaging capabilities while still integrating naturally with the existing Neutralinojs workflow.

4. Project Goals

The main goal of this project was to build neutralinojs-builder, a CLI plugin that simplifies packaging and distributing Neutralinojs applications across desktop platforms.

Supported Packaging Targets

Unified CLI Experience

The builder integrates with the existing neu CLI as a plugin instead of introducing a separate packaging system.

Developers can use commands such as:

neu builder deb
neu builder appimage --x64
neu builder nsis --x64
neu builder dmg

This provides a consistent interface while the builder handles the platform-specific packaging workflow internally.

Centralized Configuration

A key design goal was to use a single neutralino.config.json for the application.

The same configuration can provide:

• Application metadata

• Packaging targets

• Target architectures

• Output configuration

• Application icons

• Platform-specific builder options

This avoids requiring developers to maintain separate configuration files for each packaging format.

Modular Architecture

The builder was designed so that each packaging target remains independent while sharing common functionality.

The shared builder layer handles:

• Configuration resolution

• Application staging

• Dependency validation

• Logging

• Build orchestration

Individual target implementations handle the platform-specific packaging logic, validation and assets management.

5. Designing neutralinojs-builder

Before implementing neutralinojs-builder, I first had to understand how the existing neu CLI works and how its plugin system integrates with it. The builder was designed as an extension of the existing CLI rather than a separate build system, so it needed to follow the same conventions for command registration, configuration handling, and execution.

I also looked at how neu build produces the application binary and resources. The builder does not replace this process; instead, it takes the output from neu build and uses it as the input for the packaging stage. The existing neutralino.config.json is also reused as the central configuration file, allowing the builder to work with the existing Neutralinojs workflow without introducing another configuration system.

After understanding how the existing neu CLI works, the next step was to design the architecture of neutralinojs-builder. The main idea was to keep the builder independent of any particular packaging format. Debian, AppImage, NSIS, and DMG all have very different packaging requirements, so putting all of their logic into one large module would make the project difficult to maintain and extend.

The architecture was therefore divided into a common builder layer and separate target implementations. The common layer is responsible for everything that is shared between packaging formats and controlling the overall build flow. Then the builder selects the appropriate target implementation and passes the prepared application to it.

The architecture can be understood as a simple pipeline:

The Configuration Resolver is responsible for determining what the user wants to build. It reads the builder configuration from neutralino.config.json and resolves the selected target and architecture from the CLI and configuration.

The Build / Staging layer prepares the application for packaging. It works with the output produced by neu build and collects the required application binary, resources, icons, metadata, and other assets. These files are arranged into the structure expected by the selected packaging format.

After staging, the Target Loader determines which packaging implementation needs to be executed.

How the Builder Integrates with neu

The builder was designed as a plugin for the existing neu CLI rather than as an independent command-line tool. When neutralinojs-builder is installed as a plugin, the Neutralinojs CLI loads it through its plugin system and registers the builder command. This allows the builder to be invoked using the existing CLI, for example with neu builder deb, without requiring developers to learn a separate tool.

At a high level, the flow looks like this:

The plugin itself is responsible for registering the builder command with neu. Once the command is invoked, the builder passes the requested target into its core build pipeline. The pipeline first resolves the application configuration, performs environment and dependency checks, prepares a temporary staging directory from the existing neu build output, and finally loads the implementation for the selected target.

The Target Loader keeps the packaging implementations separate from the common builder logic. For example, when deb is selected, the loader resolves targets/deb/index.js and invokes its build() function. The same mechanism is used for AppImage, NSIS, and DMG. This keeps the common workflow shared while allowing each packaging target to implement its own platform-specific requirements.

Cross-platform Configuration

Another important part of the design is that developers can configure the packaging targets through the existing neutralino.config.json. The builder reads the application metadata from the main configuration and uses the cli.builder section for target-specific packaging settings.

A simplified configuration for a cross-platform application looks like:

{
  "applicationId": "com.example.myapp",
  "applicationName": "My First Builder App",
  "version": "1.0.0",
  "defaultMode": "window",

  "cli": {
    "builder": {
      "windows": {
        "targets": [
          {
            "target": "nsis",
            "arch": [
              "x64",
              "ia32"
            ],
            "icon": "./installerassets/windows/nsis/app.ico",
            "sidebarImage": "./installerassets/windows/nsis/sidebar.bmp",
            "headerImage": "./installerassets/windows/nsis/header.bmp",
            "license": "./installerassets/LICENSE.txt",
            "output": "./dist/windows"
          }
        ]
      },
      "linux": {
        "targets": [
          {
            "target": "deb",
            "arch": [
              "x64",
              "ia32",
              "armhf"
            ],
            "icon": "./installerassets/linux/deb/app.png",
            "category": "Utility",
            "output": "./dist/linux",
            "maintainer": "GSoC",
            "preinst": "./installerassets/linux/deb/scripts/preinst", 
            "postinst": "./installerassets/linux/deb/scripts/postinst", 
            "prerm": "./installerassets/linux/deb/scripts/prerm", 
            "postrm": "./installerassets/linux/deb/scripts/postrm"
          },
          {
            "target": "appimage",
            "arch": [
              "x64",
              "arm64"
            ],
            "icon": "./installerassets/linux/appimage/app.png",
            "license": "./installerassets/LICENSE.txt",
            "output": "./dist/linux",
            "maintainer": "GSoC"
          }
        ]
      },
      "mac": {
        "targets": [
          {
            "target": "dmg",
            "arch": [
              "x64",
              "arm64",
              "universal"
            ],
            "icon": "./installerassets/mac/dmg/app.icns",
            "background": "./installerassets/mac/dmg/dmg-background.png",
            "output": "./dist/mac"
          }
        ]
      }
    }
  }
}

6. Implementation / What I Built

Debian Packaging

One of the major parts of my work on neutralinojs-builder was implementing the Debian packaging target. The goal was to take the output generated by neu build and turn it into a standard .deb package that can be installed on Debian-based Linux distributions such as Ubuntu.

The builder handles the required Debian package structure and metadata and then uses the Debian packaging tools to generate the final .deb file. I also worked on the supporting pieces around the package, including application staging, architecture handling, launcher generation, and Debian maintainer scripts. This allowed the generated package to behave like a normal Debian package rather than simply being a compressed copy of the application files.

After generating the package, I tested the complete installation workflow on Ubuntu. The following screenshots show the generated application being detected by Ubuntu's App Center and the package installation interface.

The generated .deb package is recognized by Ubuntu's App Center, where the application metadata, package size, description, and installation option are displayed.

After installation, the packaged Neutralinojs application is available through the Ubuntu application launcher, demonstrating the complete flow from the Neutralinojs build output to an installable desktop application.

The Debian implementation was developed incrementally through multiple pull requests, covering the core packaging logic, staging improvements, launcher support, maintainer scripts, and packaging tests. The relevant pull requests are listed in the contributions section below.

AppImage Packaging

Another part of my work was implementing the AppImage packaging target for Linux. Unlike Debian packages, AppImage is designed to provide a more portable way of distributing Linux applications, where the application and its required files are bundled into a single executable .AppImage file.

The builder prepares the application using the same common staging workflow and then packages the staged application into an AppImage. The generated file can then be distributed directly to users without requiring a traditional package installation workflow.

After generating the AppImage, I tested it on Linux to verify that the package was created correctly and could be launched as an application. The following screenshot shows the generated .AppImage file in the output directory.

The generated .AppImage package is produced as a single executable file containing the Neutralinojs application and its required resources.

I also verified that the generated application could be recognized by the Linux desktop environment and launched like a regular desktop application. I also verified that the generated AppImage could be launched and integrated into the Linux desktop environment using AppImageLauncher.

The packaged Neutralinojs application appears in the Linux application launcher, demonstrating that the generated AppImage can be integrated into the desktop environment and launched by the user.

This implementation builds on the shared builder architecture, allowing AppImage packaging to reuse the same configuration resolution and application staging logic while keeping the AppImage-specific packaging process isolated within its own target implementation.

macOS DMG Packaging

I also implemented the DMG packaging target for macOS. The goal was to take the output generated by neu build and package it into a standard macOS .dmg file containing the Neutralinojs application and the required application bundle structure.

The builder handles the creation of the macOS application bundle and packages it into a DMG that can be distributed to users. I also worked on integrating the application metadata, icon, and required resources into the generated package so that the resulting application behaves like a normal macOS application.

I tested the generated DMG on macOS to verify that the package could be opened and that the application could be copied to the system's Applications directory and launched successfully.

The generated .dmg file is shown alongside the packaged Neutralinojs application, demonstrating that the DMG was successfully created.

The Neutralinojs application is installed and can be executed on macOS from the app finder, demonstrating that the generated DMG works correctly from packaging through application launch and appears correctly in the applications section under the macos app finder

7. My Contributions and Pull Requests

Project Links

• neutralinojs-builder

• npm package

• Neutralinojs repository

• Neutralinojs CLI repository

• GSoC 2026 Project Page

• My Github

• My fork of neutralinojs-builder

8. Challenges and Lessons Learned

One of the main challenges while implementing Debian packaging was finding a cross-platform solution that could generate .deb packages from different operating systems. We explored different approaches but could not find a suitable solution that met our requirements. After some investigation, my mentor suggested using deboa. However, deboa was not very well documented, so I had to manually inspect its source code to understand how its API handled package metadata and maintainer scripts such as preinst, postinst, licensing, and maintainer information.

We also had to evaluate the trade-offs between using deboa and the native dpkg-deb approach. I created a detailed comparison report covering both approaches and the reasons for choosing one over the other, which I will link here: deboa vs dpkg-deb detailed comparison.

For AppImage, the main challenge was investigating whether a truly cross-platform packaging solution was possible. We found that the AppImage runtime is Linux-native, meaning the final AppImage packaging process cannot simply be executed directly on Windows or macOS without a Linux environment or additional tooling such as Docker. This became an important consideration when designing the cross-platform packaging workflow.

9. Current State and Future Work

At the end of the GSoC period, all four planned packaging targets, Debian, AppImage, NSIS, and DMG have been implemented, with tests written for each target. A working version of neutralinojs-builder has been completed and the package has been released to the npm marketplace, making it available for Neutralinojs developers to use.

The current implementation will continue to be improved incrementally based on community feedback and real-world usage. One of the main areas that still needs further work is finding a truly cross-platform approach for AppImage generation. Currently, AppImage packaging requires a Linux environment because the AppImage runtime and packaging workflow are Linux-native, which limits the ability to generate AppImages directly from Windows or macOS.

Going forward, the builder can also be expanded with more packaging features and developer configuration options. The goal is to continue improving the developer experience while making the existing targets more flexible and easier to configure.

I hope to continue contributing to Neutralinojs, eventually become a core maintainer of the project and neutralinojs-builder, and hopefully return as a GSoC mentor in the future.

10. Acknowledgements

GSoC 2026 has been a really meaningful experience for me, and I am thankful to everyone who made this journey possible.

I would first like to thank Google for creating GSoC and giving students the opportunity to work on real open-source projects alongside experienced contributors. This experience gave me the chance to work on a project that went beyond a college assignment and taught me how software is designed, reviewed, and developed in a real open-source environment.

I am especially grateful to my mentors Shalitha Suranga, Athif Shaffy, and Sajath Ahamed for their guidance, reviews, suggestions. Their feedback helped me improve not only the implementation of neutralinojs-builder, but also the way I approach problems and contribute to an existing codebase.

I would also like to thank Subhash, my collaborator on the project, for working alongside me throughout the development of neutralinojs-builder.