Video summary
The August 25th, 2026 meeting of the Hyperledger Indy Contributors focused primarily on the ongoing transition from Ubuntu 22.04 and a strategic shift toward a Docker-only implementation for both Indie Plenum and Indie Node. The presenter explained that moving away from Debian packages was necessary because the tooling for creating those packages is falling out of support, which creates significant overhead. By adopting Docker images where Indie Plenum generates a base image and Indie Node builds upon it, the team aims to simplify the release workflow and streamline the overall deployment methodology. This new approach involves running tests on local environments to ensure all components pass before moving into the production phase for Indie Node.
A key discussion point centered on how future upgrades will be managed within this new Docker architecture, specifically addressing whether the upgrade process would remain manual or become automated. The presenter proposed a mechanism where an external signal could stop the current Docker container processing, allowing Kubernetes or Docker to automatically fetch and deploy the latest image upon restart based on a configured repository. This method relies on setting up a specific Docker repository where the desired image is labeled as 'latest,' giving network operators control over what gets deployed while leveraging container orchestration tools to handle the update logic without requiring a full server replacement.
Despite the potential for automation in fetching new images, the consensus was that the upgrade process would still require a manual component due to the underlying operating system changes from version 20.04 to 22.04. While scripts exist that could theoretically upgrade the OS without reinstalling servers, the team decided not to pursue that path for this specific transition. Consequently, operators will need to coordinate manually across different service servers to ensure data storage paths remain consistent and that the network stays in agreement with the new images. The presenter acknowledged that while this manual coordination is complex and may take several months to complete for entire networks, it is a necessary step to ensure reliability before fully automating the process.
The meeting concluded with an acknowledgment of the challenges involved in upgrading legacy systems, noting that previous transitions from Ubuntu 16.04 to 20.04 were also quite complex and required manual intervention despite promises of easier future paths. The team agreed to proceed with the current plan using Docker Compose configurations that point to existing data storage locations to minimize disruption, even though this still necessitates human oversight for each node. With the build processes for Indie Node currently in progress and testing phases upcoming, the contributors expressed readiness to tackle the upgrade timeline, confirming that they will reconvene in two weeks to review further developments.
Read the full video transcript
Greetings.
>> Hello.
>> How are you today, Lynn?
>> Doing all right.
>> Give me a sec here to get the
the set up here.
>> Excellent.
>> Okay.
>> All right.
I'm just making a copy of last
meeting's
notes and then we can get started here.
Um welcome to the August 25th, 2026
Indy Contributors call.
Um
we are managed by the Linux Foundation
anti-trust policy
and the Linux Foundation
Decentralized Identity Code of Conduct.
Um if you have any questions about that,
let me
paste the link in the channel here.
There we go.
All right. Um
Let me bring up one more link here
before I share my screen.
Share my screen.
Hey
um
on the agendas today, we just have the
Ubuntu 22.04 upgrade.
And do you have anything else you want
to talk about today, Lynn?
>> Nope.
>> All right, awesome.
So,
um as part of the Ubuntu 22.04 upgrade,
um what
I'm doing is I'm moving forward to a
Docker implementation only.
Um
and what this looks like is
um
uh
Indie Plenum produces Docker images, and
then Indie Node will produce Docker
images based off of Indie Plenum's
images.
Uh this simplifies the release workflow.
Instead of creating Debian packages,
there's there's a lot of overhead
getting the Debian packages working
correctly and the tooling seems to be
falling out of support.
Um and so this should simplify our
deployment methodology.
Uh what I'm showing here
is
uh in my local environment, I've got the
the build working. Uh it creates a base
image and then the production image for
Indie Plenum, and then it runs through
the the tests. And we can see that all
the tests are passing.
Um
uh and then this will move over into
um the Indie Node environment.
Um I actually don't remember where I
left off on this. I think it's still
work in progress. I think I'm working on
getting the actions triggered right now.
Um
uh and then hopefully we'll have an
Indie Node and Indie Plenum build based
off of
um Ubuntu
in a Docker container, and then we'll
move to the testing phase.
Any questions, Lynn?
>> Yeah, so I think you said last time that
the
the upgrade from 20.04 to 22.04 is going
to have to be
uh manual this time. And it sounds like
the reason is because we have to switch
to Docker containers.
>> Exactly.
>> And so what about future upgrades? Will
we There's a
There's a feature in Indie where you can
trigger an upgrade from a remote
location and it
will automatically update itself. Will
that
be able to happen in the future? Will
all upgrades from here on out have to be
manual?
>> Um I'm trying to uh make it so that
uh we can send a signal
to the Docker container to stop
processing
to to exit.
And then if your Docker image is
configured to be off of the latest image
on restart,
uh
Kubernetes or Docker, uh I'm hoping that
it will gather the the latest image
um
based on the repository that you're
configured to access. And that would be
the upgrade mechanism for the Docker
environment.
is to trigger a
um a stop
and then um rely on Kubernetes or Docker
to fetch the latest image on startup.
>> Okay, so
uh hopefully latest image is a
is configurable as well, so you can get
whatever image you want, I guess, for
so that your whole your whole uh
make sure your whole network is in
agreement with whatever image
>> Yeah, so likely for your network you
would want to set up a docker repository
and then have whatever image you want
deployed labeled as latest
in that docker repository.
Then that would
give you the control to determine
what image is being deployed on your
in your environment.
There still needs to be some testing
done on that process to ensure that we
have a reliable way to manage that.
But that's the direction I'm looking at.
>> Okay.
Sounds like it's going to be a several
month upgrade when we finally get to
upgrading the
the networks.
But that's that's where it is, so all
good.
I think that's
all the questions I have for now.
>> I'm hoping that as part of the upgrade
process we could do it in place using
docker compose.
So that we don't have to go through a
several months long process.
We just point the docker compose
configuration to use the same
data storage paths
as the previous install.
But it would still require
a manual process on each of the service
servers.
>> Yeah, that's that's the part that's the
hard part is the manual part where we
have to coordinate all the different
node operators and
and
>> Yeah.
>> help them to get through the
the
>> I think there would be a manual process.
Well, there's going to be a manual
process regardless cuz you're upgrading
your OS level, too.
>> Well, there's the scripts that can run
that will
that will make it so the OS doesn't
require an upgrade, but it we're not
doing that anyway, so it doesn't matter.
But, there's I think there's scripts
that'll upgrade from 20 to 22
without
requiring you to manually install a new
server, but I could be wrong on that, I
guess.
When we were going from 16 to 20, there
was no
path, right? You
There was no
easy path, anyway. It was quite complex,
and so that one had to be manual.
But, we were told at the time that the
future ones would not be as difficult. I
guess that was not quite true, but
that's okay.
>> Um
So, that's the status update. I'm in
process of getting the Indy node builds
worked out.
Okay.
Um thanks for
>> Anything else?
>> Thanks for coming to the Indy
contributors call. We'll see everyone in
2 weeks.
>> Bye.