Working Group: Container Config (Docker, Kubernetes)

I’m looking for individuals who can participate in a project for 2-3 months. Activities will include:

  • attending regular group meetings
  • research and communication
  • project and group organizing/management
  • contributing code to the framework
  • testing and qa

Official Container Support

There have been amazing efforts over a long period of time to containerize Redwood. The challenges to-date stem from the fact Redwood was architected for Jamstack deployment. Once we added the rw serve command, using Fastify, containerization became possible but has always involved some kind of workaround or mitigation due to side effects from original architectural decisions.


  • resolve CLI architectural blockers (design and implement)
  • define benchmarks for performance
  • determine requirements and best practices for container configuration (that satisfies 80% of use-cases): configuration, deployment steps, serve
  • design CLI command(s)
  • implement rw setup [container] (boilerplate, commands, etc.)


This project will have a Core Team lead and Community lead, who will faciliate the project and participants.

There will be regular real-time meetings. A majority of the work will take place async via Forums, Notion doc, and GitHub PRs.

Next Steps

If you have questions or suggestions, please reply below.

If you are interested in participating, please complete this form:


Hello @everyone

I’ve created a public repository with the docker tutorial repository as a base for a basic docker setup.

Things to note:

  • 3 files in api and web each (Dockerfile, docker-compose.yml &
  • the api container runs migrations on container startup
  • global yarn cache is disabled to speed up local container build time
  • there is no container size optimization done for this. it copies almost everything.
  • building can be done with a script in package.json “yarn docker-build”

For those familiar with previous posts and tutorials on the topic this isn’t much news apart from the with arguments.

This was in my opinion necessary because some variables in redwood.toml like ports, hosts and urls make it more difficult to stay env agnostic.

The redwood cli “yarn rw serve” has arguments for the apiHost to get around this limitation and therefore shows how much more could be achieved without the CLI architectural blockers.


Amazing! Thank you for creating and posting this.

Quick update:
We are planning to kick off the working group the second half of March. @dom will be leading the group and several other members of the Core Team and Redwood Startup Club will be joining. This project is going to touch Fastify, CLI, and the deployment process, which will open up a lot of possibilities for dev and deployment.

Excited to have so many interested individuals. We’ll be in touch soon!



I’ve closed the form and emailed everyone who joined. (Thanks again!)

We have scheduled a kick-off meeting for next Monday, March 27th. If you did not receive any information but did complete the form, please get in touch with either me or @dom

Excited to get this rolling :rocket:

1 Like

Initiatives now have their own Forum Category. Moved this discussion over here (and closing the thread):