Stream: containers

Topic: guidance container for production

Andres Mauricio Heredia (Jan 15 2026 at 20:59):

Hi all,
I’m looking for guidance on the recommended starting point for a production deployment of Dataverse using containers.

I’m intentionally not asking to debug my current setup — I’d rather understand how people who run Dataverse in production with Docker usually start.
Current context (already done):

• Ubuntu 24.04 server
• Docker installed (official Docker packages)
• Managed PostgreSQL database (external, not containerized)
• S3-compatible object storage (DigitalOcean Spaces)
• DataCite account active and credentials validated
• Firewall allows only HTTPS
  • Payara, Solr, DB ports not exposed
• TLS certificates installed and configured via Nginx (reverse proxy)

What I’m trying to understand:

1. For production with containers:

   • Is the official containers demo compose a valid starting point?
   • Or is it better to build a compose file from scratch for production?

2. If starting from the demo:

   • Which parts are meant only for demo/testing?
   • What must be changed or removed for production?

3. From a Dataverse perspective:

   • What is the recommended order of setup?
     • Dataverse initialization?
     • Root dataverse creation?
     • Storage + DOI validation?

4. Are there any “known good” reference setups (even informal) that the community considers production-ready with Docker?

I’m comfortable with infrastructure and security, but I’m still learning the Dataverse-specific production patterns, and I’d really appreciate guidance on the right way to start rather than trial-and-error.

Thanks in advance for any pointers.

— Mauricio

Philip Durbin 🚀 (Jan 15 2026 at 21:04):

@Andres Mauricio Heredia hi! We had a meeting just today! (See #containers > meetings). Maybe you can join the next one! Meanwhile, we can try to answer you here. :smile:

Philip Durbin 🚀 (Jan 15 2026 at 21:05):

The dev persona is what we use in development. This explains how to set up a demo persona, which is more secure than the default dev persona: https://guides.dataverse.org/en/6.9/container/running/demo.html#creating-and-running-a-demo-persona

Philip Durbin 🚀 (Jan 15 2026 at 21:06):

Does that help?

Andres Mauricio Heredia (Jan 15 2026 at 21:18):

Hi Philip, thanks — yes, that does help :+1:

What I’m trying to validate is the correct production path, because what I’m seeing is this:

• When I run the demo persona as-is, without changing anything, everything works.

• As soon as I start making what I would expect to be “production changes”:

  • moving the database outside the containers,
  • switching file storage from filesystem to S3 (DigitalOcean Spaces),
  • configuring DataCite,

  Dataverse stops working properly (sometimes it only reaches Payara, other times Dataverse starts but nothing initializes).

So my question is more about process than configuration:

• Is the recommended approach to:

  1. run the demo persona first and then gradually replace components (DB, storage, DOI), validating each step?

• Or should production be approached as:
  2) starting from scratch with all production configurations defined up front, and expecting Dataverse to initialize correctly from that state?

I’m comfortable adjusting configs, but I’m missing the mental model of how the Dataverse team expects the transition from demo → production-with-containers to happen.

Any guidance from people who’ve done this in production would be really valuable.

Philip Durbin 🚀 (Jan 15 2026 at 23:00):

I see. I would suggest starting from a working config and then making changes one by one, such as switching to S3.

Andres Mauricio Heredia (Jan 16 2026 at 07:49):

after several days of debugging I want to share a clear finding and ask for guidance / confirmation.

Observed behavior

• Using the official container demo (gdcc/dataverse + gdcc/configbaker) with Dataverse 6.9, the instance can start, metadata blocks are loaded, but the root dataverse is never created.

• The bootstrap.sh script skips execution as soon as metadata blocks exist:
  BLOCK_COUNT=$(curl ... /api/metadatablocks) if [[ $BLOCK_COUNT -gt 0 ]]; then echo "Your instance has been bootstrapped already, skipping." exit 0 fi

• Once this happens, the system is left in an inconsistent state:

  • metadata blocks exist
  • dataverse table is empty
  • root dataverse does not exist
  • Native API cannot create root (POST /api/dataverses/:root fails, POST /api/dataverses returns Bad API key or validation errors)

Important comparison

• I tested Dataverse 6.5 + configbaker: demo bootstrap works correctly.
• If I do not delete the data directory, and then upgrade containers to 6.9, the demo continues to work.
• If I start fresh with 6.9 (empty data dir), bootstrap does not create root anymore.

This strongly suggests a bootstrap regression between 6.5 → 6.9, likely related to:

• builtin users API key handling
• bootstrap skip condition based solely on metadata blocks

Impact

• It is currently impossible (at least for me) to produce a clean, reproducible Dataverse 6.9 container-based deployment starting from an empty volume.
• Manual SQL/API workarounds are unsafe because root dataverse creation is not a simple single-table insert.

Questions to the community

1. Is the container demo currently considered non-functional for fresh installs on 6.9?
2. Is there an officially supported way to bootstrap root in containers for recent versions?
3. Is this a known regression / issue already tracked somewhere?
4. For production, should Docker users assume classic install only, even if containers are provided?

Any confirmation, guidance, or pointer to the correct workflow would be greatly appreciated.

Thanks in advance.

Philip Durbin 🚀 (Jan 16 2026 at 12:05):

Andres Mauricio Heredia said:

• with Dataverse 6.9, the instance can start, metadata blocks are loaded, but the root dataverse is never created.

@Oliver Bertuch @Balázs Pataki does this sound like what @Akio Sone was telling us in the containerization working group meeting yesterday? :thinking:

@Akio Sone were you seeing the same symptoms? No root collection created?

Balázs Pataki (Jan 16 2026 at 12:09):

This morning I just checked out DV, built the 6.9 base image and then DV and it started all right with Root collection, and everything. But this is with a totally fresh instance and in "dev" only, not production.

Balázs Pataki (Jan 16 2026 at 12:12):

And I deleted all my gdcc/* docker images, so these were all built fresh

Philip Durbin 🚀 (Jan 16 2026 at 12:14):

@Balázs Pataki phew! Thanks for testing! :sweat_smile:

Philip Durbin 🚀 (Jan 16 2026 at 12:15):

But how can we reproduce what @Andres Mauricio Heredia is seeing? :thinking:

Oliver Bertuch (Jan 16 2026 at 12:26):

Not sure what's going on here. Also I'm a bit reluctant here because the description above sounds influenced by an LLM, which may foster doing things the wrong way.

Oliver Bertuch (Jan 16 2026 at 12:28):

I'm not 100% sure what @Akio Sone problems were exactly :see_no_evil: As far as I understood, he (has?) had a build problem when checking out the 6.9 code and building the images, not a problem with bootstrapping. So I'd cautiously vote for "not related".

Balázs Pataki (Jan 16 2026 at 12:30):

I would suggest to make sure to start from clean: remove all gdcc and other containers and images built/started by docker compose and start with a fresh clone of the repo so that previous attempts don't "infect" the experiment.

Oliver Bertuch (Jan 16 2026 at 12:30):

Wait a sec here - I may have an idea!

Oliver Bertuch (Jan 16 2026 at 12:31):

He says this is about bootstrapping, so configbaker related.

Oliver Bertuch (Jan 16 2026 at 12:31):

IIRC somewhere around 6.5 we started "real" tags.

Oliver Bertuch (Jan 16 2026 at 12:31):

So he may be using the unstable tag from before!

Oliver Bertuch (Jan 16 2026 at 12:32):

If @Andres Mauricio Heredia kept those around for any 6.9 experiments, that would be my educated guess where any kind of trouble may come from.

Oliver Bertuch (Jan 16 2026 at 12:33):

I may be wrong, but my non-LLM advice: first pin down these versions in both DV and Bootstrapping, try again and see what happens.

Oliver Bertuch (Jan 16 2026 at 12:35):

So basically what @Balázs Pataki said, but in more controlled manner than "delete all images". :wink: Hat tip for jumpstarting my brain! :coin: :top_hat: :smiley:

Philip Durbin 🚀 (Jan 16 2026 at 13:59):

@Akio Sone so! Please try deleting local gdcc images to get a clean test of 6.9. Thanks!

Philip Durbin 🚀 (Jan 16 2026 at 13:59):

@Andres Mauricio Heredia please keep the questions coming! We love the feedback! Again, I'm sorry we could talk to you live yesterday during the meeting!

Akio Sone (Jan 16 2026 at 15:57):

I encountered the reported issue as follows:

1. clone Dataverse as a new repository
2. check out the tag v6.9 as a new branch (commit id: e2021d3a80;tagged to the master branch, not develop branch)
3. build/run the container

4. Dataverse sub-containers were running but Dataverse (web page) seemed not working
   symptoms: Docker log (server.log) showed that an old version of Payara was still running and
   that the health check (hitting the health-check API endpoint) was continuously failing
   Don Sizemore told me that version 6.9 requires a new version of Payara server due to some recent change made by Jim

5. check out the develop branch (commit id: 96e96f4763; 2025-12-22;)

6. build/run the container
7. This time it was working with a new version of Payara server

When a new version of Dataverse is released, I set up a fresh repository for each version.
So I suspected some of the commits between the day when the tag was created and 2025-12-22 fixed the above issue although I did not dig in which commit(s) solved the issue.

Philip Durbin 🚀 (Jan 16 2026 at 16:23):

@Akio Sone that makes sense but our suggestion is to delete any gdcc containers from Docker and try the above again.

Andres Mauricio Heredia (Jan 27 2026 at 19:06):

Hi to everyone, thanks for the interest on this call for help, I couldn't do it with containers, so I made it in the tradicional installation way, and now we are in production, and we are figuring on the dataverse installations map. Thanks Again.

Philip Durbin 🚀 (Jan 27 2026 at 19:08):

No worries! The traditional way is fine! Is there any feedback you'd like to give about containers? Anything we can improve?

Last updated: Apr 03 2026 at 06:08 UTC