Deploying solid in kubernetes, anyone has experience and can help us?

Hi everyone,

Following our discussion on creating and deploying a decentralized social network : New decentralized social network, specialized in sharing public and Creative Common content

We are going to give it a try. I am checking with ecobytes to deploy a Solid server with a good storage quota per POD to allow for video storage and sharing.

For this matter, we have the following question to quick start :

does anyone have experience on deploying solid in kubernetes? Are there some ongoing efforts with helm charts, ansible, operators or anything of the kind? Would be happy to get some pointers in the community.

@Smag0 you were proposing to help in this setup, do you have some experience with the above ?

@aveltens, what about you ? I know you did dockerize Solid server, any input on these questions ?

@yala from eco-bytes is actually working on this, with another person from ecobytes.

The idea is to setup this new social network for a first maximum of 50 people, get feedback, and then scale. I am very excited in lauching this network and I am optimistic there is a demand for such a service that could trigger a wider deployment of this service on SOLID.

Thank you for your help !


Hey Walter, cool to see this started. My thoughts on what you wrote:

  1. Why do you want to use kubernetes? Seems to be total overkill for 50 people
  2. Which Solid Server do you want to run? NSS is based on the file system, which will be no fun to scale on kubernetes

sorry, i’m not experienced with kub

@walter.almeida Here is a kustomization that might be helpful for you to start with.

Notably it uses an image from my docker hub account. At the time there wasn’t a good official image to use. But you can overwrite it with just a couple lines in your kustomization based on the above (docs).

FWIW, here is a similar kustomization for @codenamedmitri’s life-server solid server:


Hi! :wave: @yala tuning in who was asked to steward the process of implementing this pod a little.

We have recorded the case for us at

in which the difficulty in hosting a Solid pod at scale boils down to providing wildcard Let’s Encrypt certificates.

Its us who brought up the idea, since we are running on bare metal and have no software-defined storage in place. Escalating quickly seemed more easily handled on K8S with Ceph et al. But we can start small on the existing infrastructure, if we figure out/choose how to solve the wildcard requirement.

Do you know of other implementations that run on different storage backends?

Thank you for the links @bengo, they greatly help in seeing a chance of succeeding here.

1 Like

I was also mildly inconvenienced by the requirement to use separate subdomains for each user in node-solid-server. It would be really nice to support subpaths per user, though that would also require being careful about preventing Alice’s namespace from being able to read/write cookies that affect Bob’s namespace.

Still not too bad. On k8s I use external-dns to manage DNS rules (though I use Route53) and cert-manager to automatically create LetsEncrypt certs for k8s Ingresses. I don’t see cert-manager referred to in the issues you linked to, so check it out.

1 Like

Yes, I missed out to link to the upstream issue in the shared infrastructure, which is

In there I am seeking the ways needed to integrate the Kubernetes components with our PowerDNS instance. Previously with Certbot in an LXD container with separate IP, this worked with accessing the PowerDNS HTTP API. This will have to be deprecated by using dnsupdate with enabling RFC 2136 support.

Does cert-manager automatically involve external-dns, when present, or do you use Route53 | cert-manager likewise? As external-dns provides direct PowerDNS support, it would be favourable to prefer it over RFC-2136 | cert-manager.

Maybe it can also be a good idea to evaluate GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely. as a nice intermediary.