Some of the prospective users of Incus would be those that have been using LXD since the old times. I think we also want a path for them to choose to migrate to Incus. There is a migration path and they can certainly reuse their old knowledge in Incus without much extra work.
How this would be used in the documentation is up to discussion. I think it should certainly be in the documentation. There is a migration tool (in Incus) for certain versions of LXD that can one-shot migrate to Incus. Someone can enhance that tool to include more recent stable versions (if it has not been done already), or it could be feasible to export the instances from LXD and import to Incus.
I can see how what I said could be read in that way. There’s probably a better/clearer way to get that message through that Incus can ingest an OCI tarball and unpack that via umoci into an LXC compatible environment.
It might be useful to offer comparisions to things like Proxmox VE and VMware ESXi as well. Proxmox has gained further popularity for those let down by VMware’s licensing changes, while at the same time migrating from Proxmox to Incus is desirable for many (see this reply for example IncusOS instance VLANs and static IP-addresses - #9 by raiguard).
Hello all, I hope it’s ok for me to add a submission for a new Incus intro for the website.
Welcome new and experienced homelabbers, self-hosters, small and large companies, and enterprise.
Incus is the most light weight and flexible platform for quickly spinning up your VMs, LXC and OCI containers on any machine whether a Raspberry Pi, mini pc, laptop, desktop pc or rack server.
Whether you’re looking to host up a local media server like Jellyfin or manage hundreds of critical services for your organisation Incus is the platform for you.
Incus provides flexibility and scalability for various use cases, with support for different storage backends and network types, all managed with a simple command line tool or GUI, and directly through the REST API or by using third-party tools and integrations. Incus implements a single REST API for both local and remote access.
The Incus project was created by Aleksa Sarai and most of the original creators of LXD to remain a fully open source and community driven project.
It’s not easy to nail the text right. If one really intends to targets enterprise, they usually are not appended to a list after homelabbers and self-hosters. And presentation should be improved as well, it’s not just the content.
Then, at the same time, there are ambiguities. This still stands as articulated by @chuckboecking:
The project does not clearly state its goals anywhere (that I can find). I believe it should. I do not think we can state them. I would love to see this coming from the core team.
Building visuals and a particular style around the name of the project, as explained in,
is also an intriguing consideration. This is just a slightly revamped logo for when showing larger resolutions are feasible which intends to better display the identity of the project:
That is correct, and my wording was not on point. Although, – set me straight if I am wrong – Incus is the “flagship product” of said organization and maybe it’s time for it to declare and present itself as such.
Nope, the organization is called Linux Containers, or with its short name, LXC. Following that, LXC would be the flagship product, used in a ton of downstream projects, e.g. Proxmox, OpenNebula or libvirt to name a few. But there’s really no flagship or anything. All the projects listed on the website have their own relevance. LXC is just an umbrella organization focused on projects managing virtual resources at different stages of the chain.
Alright. So we can establish that Incus does not have a logo, nor any branding practically. It however does boast paid/official/enterprise support via Zabbly while LXC doesn’t. So in this sense it may be closer to an actual product than LXC.
By the way, interestingly, LXC is not mentioned as a core dependency for Incus on either the GitHub page or at the linuxcontainers.org introduction page.
I was thinking about how Tailscale markets itself. The ultimate goal is paying business and enterprise clients. I believe how they target the end goal, at least when establishing a name for themselves, was/is via the homelab community. Many homelabbers work in IT and when impressed with Tailscale’s use and strong features then went on to recommend that their organisations switch to using it.
Building an identity is something a brand needs. Incus is developed by individuals, some of them happen to be hired by a company whose whole business revolves around Incus, some of them by a company that just uses Incus, and some of them aren’t even hired by a company (that’s my case, I’m a civil servant). We could lean into more corporate bullshit, but why? If you want the project to be more known, then talk about it, build something on top of it, or even sell your own services.
That being said, sure, the front page deserves some more love.
Many open source projects, from Gnome extensions, docker apps like Hortusfox to Open Media Vault at least have their logo. That doesn’t need a marketing department. The community could create some to be put forward for a community vote. I do try to. I think that will be easier when Incus has its own UI, not a LXD fork, which Stephane has discussed is coming.
This “constructive challenger” tone of mine throughout this thread is due to the fact that I want to invest more and more in Incus (I do actually each day for a while now again) but at the same time I am afraid that I am investing in something with an uncertain future. That is too much dependent on Stéphane’s will to keep developing it and the state of the related company, FuturFusion (sorry for not including other contributors). If Incus had more definite presence, introduction, branding, a roadmap, might I say, a future, I would be much more comfortable with building on top of it. Also, when I realized not too long ago that none of my 20 teammates who were engaged in Linux-specific software development knew about Incus, that added to my anxiety.
lean into more corporate bullshit
At least the bare minimum. Quality and community over anything else is something I believe in myself as well, but there is a market, a playing field, and I can’t see how this project can afford to not distinguish itself, to not take sweet corporate money, and maintain the level of quality overall that is on par with competitors’ solutions who do reap in these resources and assurances.
It’s one thing what assurances the maintainer seeks, and another what the consumers of his/her software would like to see. It’s not necessarily that I have worries the project will lose its momentum, it’s that I cannot present or defend the stance properly why I chose this as a dependency against other alternatives. The observation that Incus has bad introduction, the original title of this thread, is one of the factors in this.
