State of Nassella: July 2026

Mission: make self-hosting accessible to everyone!

Problem Space: self-hosting is hard! It provides benefits like having control over data and software but deploying and maintaining a secure web server is difficult or impossible for most people. Nassella exists to automate the entire operational layer while still keeping users in control.

Product: an open source "control plane" that deploys immutable instances for popular apps (NextCloud, Ghost, etc) and configures the Apps, DNS, HTTPS, and everything else needed to securely deploy and maintain self-hosted apps without needing DevOps experience or deep technical knowledge.

Team: Thomas Hintz (founder, lead architect) – bringing: 25 years of open source software engineering, 5 years of engineering management , and 15 years of self-hosting experience. Host of The React Show. Author of Foundations of High Performance React. Creator of many open source libraries.

Governance: The company is currently primarily me, Thomas, and one other potential member, but I am actively looking for more members to join. Once we have at least three committed members we will form a worker's cooperative to ensure the long-term sustainability of Nassella.

Summary:

• Nassella now successfully deploys and maintains production self-hosted applications.
• It is already running several production services, including this website.
• The core architecture has been proven.
• The next milestone is polishing the first version and funding continued development.

Completed So Far

As this is the first "State of Nassella" report, it covers everything developed so far, which is nearly a year of work, so, a lot. :) First I'll go over the features that have been completed and then the upcoming roadmap.

The TLDR: I've already been using Nassella and it is currently used in production to host this site, running Ghost, as well as www.nassella.org, running Wordpress, and Nassella at app.nassella.org. It also runs NextCloud, wg-easy, as well as Dozzle for logging. It also hosts itself! Nassella can be used to host Nassella, which is always fun!

So far there I have made 124 commits totaling around 9,000 lines of code. I hand wrote them all, if that matters, no AI. And that doesn't include a support library I wrote for it called html-widgets.

My main goal for an initial release is to prove out the idea and have something functional for someone that is more OK with having to do some work on their own to get everything to work while at the same time ensuring the foundation of the project is setup well for the long-term goal of making self-hosting accessible to everyone!

The following is a quick summary of the work done so far.

• Nassella Instances (the actual deployed instances, like the server that hosts the Ghost app running this website)
  • Flatcar container Linux configured to run Docker Compose and with automatic updates enabled. This provides a secure and reliable foundation for instances.
  • Instance data layout that separates and secures app configuration from app data, with app configuration being set to "read-only". This provides a secure foundation, eliminates config "drift" as well as enabling simple backups and snapshots.
  • systemd unit that runs on a daily schedule to encrypt and back up all application data to an offsite restic repository hosted on Backblaze B2. This makes regular, off-site, backups easy and "hands off".
  • systemd unit that can receive authenticated "control" commands, currently used for creating app snapshots/backups when requested by a user or before a deployment. This makes it so the instances do not need SSH or user login and ensures any actions done to an instance are authenticated and authorized and it also prevents breaking instances with "hand tweaks".
  • systemd unit that runs a docker compose configuration that comprises all of the apps a Nassella user has selected to run on the instance. This powers all of the Apps that Nassella supports and ensures the apps start and run successfully.
  • Caddy setup providing TLS termination for all apps. This ensures all Apps use secure connections and also, combined with Docker, isolates apps from each other and from the open internet.
• Control Plane (the system used to deploy and maintain Nassella Instances)
  • command-line interface to deploy and maintain a single Flatcar Linux system hosting supported Nassella Apps
    • Makefile based system for easily adding apps including their docker compose config and any other scripts or configuration needed to setup an App to run on Nassella. This makes it easy to develop, add, and test Apps without needing complex environments or tooling.
    • Centralized config folder containing all of the configuration needed to run a Nassella Instance. This makes trivial to add support for new apps without having to worry that they might break something else in the system.
      • apps.config – contains all configuration needed to run all of the apps on a Nassella Instance
      • production.tfvars – terraform configuration needed to deploy a Nassella Instance
    • "make" recipes for deploying a Nassella Instance via Terraform.
    • Minimal dependencies: bash, make, docker, terraform. This makes it easier to test and also enables the potential for other "front-ends" for different use-cases.
    • Versioned docker and config support for: NextCloud, Ghost, wg-easy, Dozzle, Nassella, lldap, authelia. This enables users to run different versions of apps and to upgrade/downgrade when they want. It also makes it easy to add support for new App versions without breaking old versions.
    • Terraform support for deploying to DigitalOcean and configuring DNS via Cloudflare. Using Terraform in this way makes it easy to ensure instances are always in a valid state as well as making it trivial to migrate between servers and providers.

• web app (provides an easier to use interface and supports multiple instances across multiple tenants)
  • CHICKEN Scheme based web application that internally calls the command-line interface to deploy and manage Nassella Instances. Not everyone wants to or should be required to know how to use a command-line program so this makes self-hosting more accessible to more people.
  • Postgres database for storing all instance and tenant data.
  • Minimal user data is stored in plain text: user's email, user's username, an instance's installed apps and versions, the "root domain" for an instance, instance deployment datetimes and statuses. A core principle of Nassella is to keep as much data as possible in user's hands and not available to any third parties. It is much better to not have the data at all than to attempt to secure it or try to guarantee it won't be used for other purposes.
• Sensitive user data encrypted (with AES-256-GCM) to prevent database leaks from causing important info to leak. Security is taken very seriously, including attempting to cover scenarios where there is a breach. The goal is to minimize the affect of a breach and have "defense in depth".
  • Each user gets their own encryption key which is encrypted by a master key kept outside of the database. Even if an attacker gets access to the database they will not be able to read any sensitive data.
  • Encrypted info includes: API keys, app configs, Terraform state.
• Setup wizard for creating, configuring, and deploying an instance. Transparently and automatically handles creating and storing any necessary JWT tokens, database passwords, etc for apps. The design is to make it as easy as possible for anyone to self-host!
• Instance dashboard showing deployed instances, apps, and an interface to update app configurations.
• Backup/snapshot interface for viewing Restic snapshots, restoring snapshots, and creating snapshots. Restic was chosen for being a well developed open source solution that includes high-quality encryption as well as de-duplication, which makes off-site backups more affordable.
• Authelia used to provide authentication including MFA. It was judged that using an existing open source project to provide authentication would be more secure and robust than developing one from scratch.

Upcoming – V1 Release

While Nassella is currently available to use, it really still has a lot of rough edges that need improvements before Nassella is ready for wider use. The "V1" release is all of the changes needed before that. You can see an up-to-date list on the Gitea tracker here: https://code.thintz.com/nassella/app/milestone/1

• Known bugs:
  • Input validation for subdomains. #43
  • SMTP config for Ghost may need tweaking depending on the port used. #47
  • Instance "destroy" action is currently not fully working. #14
• Features:
  • Improving the sign-up flow. This currently requires resetting your password via Authelia before you can login, which is awkward and unexpected.
  • Removing the now unused "admin" username/password for the old HTTP auth system used for viewing the logs
  • Hide things from the UI that an end user doesn't actually need to see or care about like the "instance-control" app
  • Cleaning up the Dashboard so it looks better and the documentation links all actually work
  • When deploying an instance, also have a status for when the new instance is actually booted. Currently, you just have to wait for a minute or so until the instance websites start responding.
  • Delete the app deployment folder used for the command-line interface after a deployment is complete. This would make the control-plane more secure.
  • Do a high-level security review and create a document detailing the current state of security for Nassella.
  • Detect common Terraform operation failures like a DigitalOcean API error and navigate the user through it (via re-trying and/or documentation).
  • Before deploying an instance, run terraform "plan" to detect if the application data will be deleted and ensure a snapshot is taken first and then ensure the snapshot is restored on boot of the new instance

Upcoming – V2 Release

Hopefully V2 can be released soon after V1 as it contains many very important features but they just didn't seem 100% required for first use. You can see an up-to-date list on the Gitea tracker here: code.thintz.com/nassella/app/milestone/2 I expect this might change a lot based on feedback but this is the current vision:

• Provide a way to "eject" from Nassella by providing a way to download an instance's "config" folder so it can be used with the command-line interface program independent of the rest of the Nassella architecture.
• Setup ldap further so that only users in a "log viewer" group can view an instances logs. Currently all users can view them.
• Provide a mechanism for a user to "reset" an app's data
• Improve the web app interface to better support updating apps and give the user more control over updates.

V3

I would love to add support for more apps in V3 and it would be good to add support for other VPS's and DNS providers. I feel like it is best to get the system working well before adding more apps or providers, at this point.

Security

I take security extremely seriously. I have continually been disappointed when working for tech companies when it comes to how they treat security, especially startups. The only time they really care much about security is when it might make them look bad. They never prioritize security because it is the right thing to do to protect their users. Nassella is not like that. I put security of users and their data above anything else. That being said, I am not a security expert. I have many years of experience and I have studied many aspects of security but I still plan have regular external security audits performed with all of the results made publicly available, as soon as Nassella has enough revenue to afford it.

My approach to security so far has been to develop good fundamentals. The first thing being using an OS for instances that is more secure by default: Flatcar Container Linux. Flatcar is specifically designed and audited to significantly reduce the attack surface of a Linux system, by design. It does this be being an "immutable" OS. The core OS is immutable and cannot be changed even by a logged in "super user". The OS also comes with automatic updates on a two-week schedule, along with many other security features.

Flatcar also includes support for SELinux. I do not currently have it enabled on Nassella instances but it is my goal to get to a point where it can be enabled.

I have also designed the Nassella instances so that the App configurations are also "read-only", and, like the rest of the core Flatcar system, they cannot be changed even by a logged in "super user".

I have also taken a lot of care when architecting the Docker Compose configuration for all of the deployed Apps by ensuring apps are isolated from each other on separate networks and with separate writable data directories. All Apps are also behind a Caddy load-balancer and only the specific programs that actually need to be accessible to Caddy are on that network. One area that could be improved though is running every app "rootless" and with separate UIDs/GIDs. This is supported and I plan to do it when Nassella gets the resources to fund it.

Of course, no system can stay secure if it is not kept up-to-date. A huge part of Nassella is ensuring that it is easy to update applications and deploy those updates. This means versioning all of the configuration for all apps, testing updates before they are enabled, and taking snapshots of all application data before updates so it is trivial to rollback an update if needed, without having to worry about losing any data or breaking the configuration. It should always be possible to rollback any update to the exact state it was before, with just a few "clicks" or commands.

A longer-term goal would be to provide a better solution for storing secrets, like a TPM or secure vault. This is technically feasible but has not been prioritized yet, especially since the base Flatcar system is inherently more secure, especially since it has no way to log in to the system. But it would be better long-term and provide more "defense in depth" to use a better method for storing secrets than OS protected files, as is being done currently (generally via Docker secrets).

For the hosted version of Nassella, I also have put a lot of effort into ensuring that any sensitive data is kept secure and segregated, including any API keys or deployment states. All data that is not needed by Nassella, which is most data, is kept encrypted via AES-256-GCM. The rule I operate by is: if Nassella does not need the data for performing system-wide queries, then it will be encrypted. (An example of a system-wide query, would be a query that looks for any instances with Apps that have updates available; therefore the App name and version are left unencrypted). Each user has their own encryption key which is also encrypted by a key that is not stored in the database. Longer-term I would like to store the keys in a TPM or secrets vault but that has not been prioritized yet.

I also put a lot of effort into standard web app security measures like preventing SQL injection by utilizing industry best practices.

Overall, I believe the security goals of Nassella are well aligned with respecting users and the security currently has good fundamentals but I would love to have more funding to spend more time on ensuring the security is as good as it can be.

So far it has been mostly just me. One other person has spent around 15 hours learning how some of the code works but all of the product development, programming, and testing was done by me.

Finances

Until this point I have paid for everything out-of-pocket without a salary; which translates to a lot of personal debt, in this case, to cover my living expenses. Actual operating expenses for the company itself are very minimal, aside from that.

Current Operating Expenses

With Backblaze I have not even triggered any threshold to pay anything yet even though I am storing about 1.6GB, what a deal!

DigitalOcean has been hosting both the nassella.org instance as well as other testing instances and the actual monthly costs vary.

While I don't expect any significant changes in operating expenses for vendors I will need to start drawing a salary from the project soon if I am to continue being able to work on it at any significant capacity. I will post about that separately. Once there are some users vendor costs may increase some to pay for email hosting.

By far the biggest investment we can make into Nassella would be to increase revenue and crowd-source investment that would allow us to put more time in to Nassella. This is one of my primary goals in the short-term. I estimate that to deliver a more production-ready V1 the cost will be about $6,080, with the following cost breakdown:

This assumes paying an hourly pre-tax wage of $40. This is the minimum I need to earn to survive where I live. Engineering work will be primarily done by me and I have some help for things like documentation.

The goal is to make Nassella financially sustainable as soon as possible. I believe reaching financial sustainability and growing community involvement is the best way to ensure we reach our longer term goal of making self-hosting available to everyone. To me this means having enough revenue to cover minimal expenses and wages. I currently estimate this to be around $7,000 per month to cover wages and vendor expenses.

I am also committed to donating 5% of the revenue over expenses to the open source apps that Nassella supports.

Revenue & Funding Sources

The ideal would be able to raise recurring revenue from people that use the free versions of Nassella, via things like Patreon, as well as paid users of the hosted version of Nassella. I am also open to sponsorships from corporations that want to support the project in general or are interested in us adding support for a specific App. This report will be being released at the same time as I plan to start marketing Nassella as being open for donations and sponsorships and for early access beta users of the hosted version of Nassella. For now though, there is no recurring revenue.

Structure

The goal is to structure Nassella as a worker's cooperative. This means Nassella would not just be another tech startup trying to make people rich. Currently, it is just me so that is not possible but I am actively looking for people to join to make that possible in the near-term. I am committed to structuring the co-op to incentivize long-term respect for end-users. Nassella will be both a great long-term place to work as well as a company that builds products focused on empowering and respecting users. It is not structured to maximize short-term profits or for an "exit". It is designed to be able to sustainably produce high-quality software for the long-term.

I am also researching ways in which the users of the product(s) can have real input and representation within the company itself. If you have ideas on how to do that, please let me know!

A primary goal is one worker equals one vote along with voluntary and open membership. Having more equity in the company does not mean more power or control over the direction of the company and it also excludes any external investors from being able to exert any power or control. It also means making an active effort to prevent any discrimination including, but not limited to: gender, social, sexual, racial, political, or religious discrimination.

This also means developing bylaws that require all major changes to require consensus vote of all members. This would include hiring and firing. It would also mean the co-op and its members may not enter into any agreements that would cause the change of control, such as giving an outside firm or investor control.

I am very excited about the future of Nassella! It is one of the things I am most proud of in my life and I think it can make a real difference in making the world a better place and loosening the grip exploitive corporations have over technology today.

At the same time, this is a critical moment for Nassella and the next few months will likely play a large role in determining the direction that Nassella is able to go. If you want to be a part of fighting back against big tech and you believe in the vision of making self-hosting accessible to everyone, then I would be thrilled to have you join me!

• Spread the word! Tell people why you're excited to make self-hosting more accessible!
• Donate: Patreon, Buy-Me-A-Coffee
• Sponsor: sponsor an App or feature, or in general. Send me an email nassella [at] thintz.com
• Contribute: code or documentation – send me an email at nassella [at] thintz.com if you are interested and I'll get you setup.
• Become an early beta user: send me an email at nassella [at] thintz.com