create before start issue

[alexanderankin]

this ticket discusses nuances about creating containers before starting them

[rhoban13]

My main question is would we allow clients access to containers which are created, running & stopped? Currently the Container._container will pretty much only be in the running state, b/c the current start method calls run. While we certainly could make the start method do create + start, another option may be to expose a .create method, and then start could check if _container has already been created for backwards compatibility. That'd afford the opportunity for callers to operate on the created container prior to starting, getting semantics much closer to the docker cli & api. Yet another option may be to create the container in the initializer directly, so an instantiated class always corresponds to a created container.

For reference (best of my knowledge, please correct me)

Things you can do prior to starting a container:

1. Connect additional networks - what would the behavior of with_network be on a created container. Currently it looks like we only support one network, but I believe you can connect to multiple in theory. One during creation
2. Copy files in/out. Would this be supported with with_copy_into_container or copy_into_container?

Things you can't do prior to starting a container:

1. Several places where we check if self._container will raise ContainerStartExecption ( here in get_logs for example). That may need to check something about the state of the container, or maybe blindly call the relevant docker_client commands and let those exceptions propagate. Could also potentially wrap those into something more user friendly.

Stopped container:

1. We currently remove the container upon stopping. I've run into this before whereby I wanted to inspect stopped container logs and was unable to without overriding the stop method. Should we afford users the ability to work with a stopped container?

[alexanderankin]

So for stopped container I would recommend using a debugger but if there is a simple fix maybe we can explore, thinking about the others have look at the code for them

…

On Thu, Apr 2, 2026, 9:21 AM Ryan Hoban ***@***.***> wrote: *rhoban13* left a comment (testcontainers/testcontainers-python#997) <#997 (comment)> My main question is *would we allow clients access to containers which are created, running & stopped*? Currently the Container._container will pretty much only be in the running state, b/c the current start method calls run. While we certainly could make the start method do create + start, another option may be to expose a .create method, and then start could check if _container has already been created for backwards compatibility. That'd afford the opportunity for callers to operate on the created container prior to starting, getting semantics much closer to the docker cli & api. Yet another option may be to create the container in the initializer directly, so an instantiated class always corresponds to a created container. For reference (best of my knowledge, please correct me) Things you can do prior to starting a container: 1. Connect additional networks - what would the behavior of with_network be on a created container. Currently it looks like we only support one network, but I believe you can connect to multiple in theory. One during creation 2. Copy files in/out. Would this be supported with with_copy_into_container or copy_into_container? Things you can't do prior to starting a container: 1. Several places where we check if self._container will raise ContainerStartExecption ( here in get_logs <https://github.com/testcontainers/testcontainers-python/blob/87332c1332a30b673aac919b48e296e21f2c1baf/core/testcontainers/core/container.py#L310> for example. That may need to check something about the state of the container, or maybe blindly call the relevant docker_client commands and let those exceptions propagate. Could also potentially wrap those into something more user friendly. Stopped container: 1. We currently remove the container <https://github.com/testcontainers/testcontainers-python/blob/87332c1332a30b673aac919b48e296e21f2c1baf/core/testcontainers/core/container.py#L229> upon stopping. I've run into this before whereby I wanted to inspect stopped container logs and was unable to without overriding the stop method. Should we afford users the ability to work with a stopped container? — Reply to this email directly, view it on GitHub <#997?email_source=notifications&email_token=ACECGJAQOCIIOLG3RUUR5G34T2HRHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJXHA4TQOJVGIYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4178989520>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACECGJDIVMT4DPBBWRHOYFD4T2HRHAVCNFSM6AAAAACXKW2AWOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNZYHE4DSNJSGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Tranquility2]

I'm sorry but I need to ask the obvious, if one needs a file in the container prior to is start don't you usually do it as part of the Docker-file/Build process? we do support images and that's the main flow I imagine (other than some interesting debug cases).
What I'm trying to say is that the use case is not very clear to me (copying stuff to the container but not the image + doing it before anything even starts)
Going back to the original PR "This is often crucial like when you want to copy in a config file which is used by the entrypoint script or even more: if you copy in the actual entrypoint script the container should start with." This sounds exactly like something that I would personally do in the build stage (btw I used temp local images with testcontainers and its great)
Help me out, what am I missing?

[alexanderankin]

this is a feature of testcontainers in other languages and its very useful. building local images is kind of a lot of extra work imo

[guenhter]

To also give a practical use case for this: We use the https://github.com/cdelmonte-zg/nanoidp/pkgs/container/nanoidp image which supports comprehensive configuration via config yamls. Now, to test different scenarios, we have about 15 different configs for different tests. When the container is started, the configs must be in place to have them picked up.

• Pre-building the docker image would be very impractical as we change a log in the configs
• Mounting in the configs is also very annoying, as we have different environments including docker-in-docker, what makes mounting very hard.

Copying in files after creating but before starting the container is IMO the easiest option.