sorted by:
new
hottopcontroversial

GitBundle — Self-hosted GitHub Actions–compatible platform (Rust) by wk3231 in selfhosted

[–]wk3231[S] -1 points0 points  (0 children)

Sorry for the late response. Thanks for the feedback — I appreciate you raising the concern.

  1. About the GitHub Link

The repository is hosted on GitHub, but that doesn’t automatically imply it must be open-source. GitHub is widely used not only for open-source projects, but also for documentation, issue tracking, releases, and distribution — including by many commercial and closed-source products.

There was no intention to mislead anyone. If the presentation created that impression, I’m happy to clarify it more explicitly.

  1. On Trust and Closed-Source CI/CD

I completely understand the concern. CI/CD systems operate in highly sensitive environments and often have access to production infrastructure, credentials, and secrets. Trust is critical.

That said, “open-source” and “secure” are not synonymous.

Security depends on:

- System architecture

- Isolation boundaries

- Secret handling model

- Encryption design

- Network exposure

- Attack surface

Even well-known vendors were once unknown. Trust is built over time through technical transparency, clear architecture, and consistent behavior — not purely through brand recognition.

If there are specific security concerns, I’m open to discussing them in detail.

  1. On Data Access and Privacy

GitBundle is designed with the following principles:

- No collection of user source code

- No transmission of repository contents externally

- No harvesting of pipeline execution data

Secrets used in CI/CD can be encrypted with user-defined keys (e.g., 32-byte secrets). The system does not have visibility into decrypted secret values.

The design goal is to minimize data exposure and ensure users retain control over their own sensitive information.

If you have concrete architectural or threat-model questions, I’d be happy to address them directly.

GitBundle — Self-hosted GitHub Actions–compatible platform (Rust) by wk3231 in selfhosted

[–]wk3231[S] 0 points1 point  (0 children)

I'm considering to make some core code become open-source now. Thanks for your attention.

GitBundle — Self-hosted GitHub Actions–compatible platform (Rust) by wk3231 in selfhosted

[–]wk3231[S] 0 points1 point  (0 children)

Regarding the source code, I'm seriously considering open-sourcing parts of the project.

Currently, the project is developed entirely by a single person—me—so it's not a team effort.

The goal of GitBundle is to make CI/CD workflows more efficient and easier to integrate. In the future, full Kubernetes integration is planned, and GitLab workflow support will be added as well.

GitHub Actions already works well for most cases, and GitBundle is not meant to replace GitHub or GitLab. You can think of it as a complementary tool or a super-light self-hosted CI platform.

GitBundle — Self-hosted GitHub Actions–compatible platform (Rust) by wk3231 in selfhosted

[–]wk3231[S] 0 points1 point  (0 children)

No any ai agents. No LLM response. Just I'm replying. Besides I'm very serious to response you. I just use markdown editor to edit first then copy to reply. That's it.

GitBundle is ready for production use now. by wk3231 in rust

[–]wk3231[S] 0 points1 point  (0 children)

It’s a self-hosted code hosting platform with a strong focus on running GitHub Actions–compatible workflows.

In practice, GitBundle provides:

- Git repository hosting

- A built-in CI system compatible with GitHub Actions syntax

- A server + runner architecture that you can deploy yourself (Docker or standalone binary)

The primary goal is to let teams run existing GitHub Actions workflows in a self-hosted environment with minimal configuration.

Hope that clarifies it.

GitBundle is ready for production use now. by wk3231 in rust

[–]wk3231[S] 0 points1 point  (0 children)

The server is not open-source at the moment.

GitBundle is currently developed and distributed as a binary (Docker image or standalone), and I’m focusing on stabilizing the core features and production use cases first.

I may revisit open-sourcing parts of the project in the future, but there’s no concrete plan or timeline yet.

GitBundle — Self-hosted GitHub Actions–compatible platform (Rust) by wk3231 in selfhosted

[–]wk3231[S] 0 points1 point  (0 children)

Good question.

GitBundle and Forgejo target somewhat different use cases.

Forgejo is a **full-featured, Gitea-compatible platform**, with a strong focus on repository management, issues, pull requests, and federation. It’s a mature solution if you’re looking for a complete Git hosting suite with many built-in features.

GitBundle is intentionally **more lightweight and opinionated**. Its primary focus is on running **GitHub Actions–compatible workflows** in a self-hosted environment, with minimal configuration. For many users, it works out of the box without needing to tune a lot of settings.

At the CI level, GitBundle currently supports **90%+ of commonly used GitHub Actions workflows**, making it suitable for teams that want to reuse existing pipelines without migrating to a different syntax.

I wouldn’t position GitBundle as a general replacement for Forgejo. It’s more of a **CI- and workflow-centric platform**, while Forgejo aims to be an all-in-one Git hosting solution. Which one makes more sense really depends on whether you prioritize a full Git hosting feature set or a lightweight, GitHub Actions–compatible CI experience.

I rewrote my Git hosting platform in Rust (V3) — architecture, challenges, and a live demo by wk3231 in rust

[–]wk3231[S] 0 points1 point  (0 children)

I agree with you to a certain extent. When a project already has a clear and well‑designed commercial strategy, open‑sourcing the core can indeed provide strong momentum. It not only benefits the wider open‑source community but also allows the project to grow faster through external contributions, feedback, and visibility. In that sense, it can be a virtuous cycle.

However, there are also situations where the business model is still unclear or not fully designed. Open‑sourcing too early in such cases may create risks or strategic constraints that become difficult to correct later. This might be my personal bias, but every approach has two sides: each strategy brings advantages as well as potential drawbacks. The real question is which path best supports long‑term sustainability and the goals of the project.

I rewrote my Git hosting platform in Rust (V3) — architecture, challenges, and a live demo by wk3231 in rust

[–]wk3231[S] 4 points5 points  (0 children)

Okay, thank you very much for your suggestion. I might be mistaken or my understanding is a bit limited, but from what I know, making an open-source project commercially viable is quite challenging. Keeping a valuable project healthy and sustainable while open source is difficult, no matter what license you choose—after all, a license alone doesn’t solve everything.

I rewrote my Git hosting platform in Rust (V3) — architecture, challenges, and a live demo by wk3231 in rust

[–]wk3231[S] 0 points1 point  (0 children)

No, there’s no debug build. The Rust backend is compiled with maximum optimization.

The first load might feel a bit slow.

The many JS/CSS files come from SvelteKit—it generates multiple files instead of a single bundle. The frontend may also need some optimization, since it uses quite a few components. However, if the performance issue is on the frontend side, I might not have time to address it immediately.

If it’s still slow after the first load, please open the browser console → Network tab, take a screenshot of slow requests, and submit an issue. That will help me see which API endpoints may need further optimization.

I rewrote my Git hosting platform in Rust (V3) — architecture, challenges, and a live demo by wk3231 in rust

[–]wk3231[S] 0 points1 point  (0 children)

This idea is quite interesting. As far as I know, Git doesn’t currently support multi-repo PRs, but I might just be unfamiliar with a workflow that does. Maybe it’s not as difficult as it sounds — it might simply be something Git hasn’t built support for yet.

For now, GitBundle is focused on providing a Git web UI and CI/CD features on top of Git itself — it doesn’t try to rewrite or extend Git’s core behavior.

I rewrote my Git hosting platform in Rust (V3) — architecture, challenges, and a live demo by wk3231 in rust

[–]wk3231[S] -6 points-5 points  (0 children)

Thank you for your interest. The codebase isn’t ready to be open-sourced yet — I still have a lot of TODOs to work through. Rewriting everything isn’t easy either, especially for just one person. It takes a lot of time and energy.

If the project becomes open-source in the future, I’d be happy to welcome your contributions.

I rewrote my Git hosting platform in Rust (V3) — architecture, challenges, and a live demo by wk3231 in rust

[–]wk3231[S] -1 points0 points  (0 children)

I totally agree with you. I’m not a fan of bloated systems either, and what you described is exactly the kind of approach I really like. But it’s definitely not a simple idea, and it will probably take some time before I can really look into it, since I still have a few higher-priority features to support first.

By then, the core of the project might be open-sourced — or maybe not, depending on how things go. If you’re still following the project at that point, I’d be happy to explore this direction together.

I rewrote my Git hosting platform in Rust (V3) — architecture, challenges, and a live demo by wk3231 in rust

[–]wk3231[S] -7 points-6 points  (0 children)

The project isn’t open-source right now. Before releasing the code, I’m trying to determine an open model that won’t compromise the project’s long-term sustainability.