Post-Create Phase
The last mile of workspace bootstrap — linking wrappers, configuring the shell, generating local configuration — once the container and content are in place.
- Kind
- Lifecycle
- Domain
- Environment & Tooling
- Applies at
.devcontainer/lifecycle/post-create.d/- Status
- Stable
- Source · managed
.devcontainer/lifecycle/post-create.d/README.md
01 Defines
The postCreateCommand phase: scripts in post-create.d/ that run once the workspace is fully available and the earlier creation-time phases have completed.
02 Applies when
- A task answers “what should be configured so this repository is ready for development”.
- Setup needs the container, the repository content, and earlier phases’ output all at once.
03 Boundaries
- Common or reusable tooling belongs in a devcontainer feature when one is available.
- Work that should repeat on every start or attach belongs in post-start or post-attach.
- Responses to repository content being created or updated belong in update-content.
Expected behaviour
- 01Scripts run once after creation, after on-create and update-content.
- 02Scripts are idempotent so workspace setup remains safe to rerun.
- 03The phase configures the workspace; it does not install shared toolchains.
Behaviour#
Post-create is the final creation-time phase. By the time it runs, the container exists, the content is synchronised, and dependencies are restored. What remains is wiring the workspace together so it is ready for development.
The line with Update-Content Phase is about purpose rather than timing. Update-content reacts to repository content and may rerun when it changes; post-create configures the workspace once, using whatever is now in place.
Good uses
- Linking
$WORKSPACE/tools/binto a stable path such as/opt/devcontainer-tools - Configuring shell startup files so container-provided settings reach the preferred shell
- Generating local configuration, such as Terraform defaults derived from repository conventions
Avoid
- Reusable tooling that an available devcontainer feature already provides
- Work that should rerun on every start or editor attach
- Responding to content being created or updated
Examples#
#!/usr/bin/env bash
set -euo pipefail
ln -sfn "$WORKSPACE/tools/bin" /opt/devcontainer-tools
ln -sfn replaces an existing link instead of failing on it, so the hook can be
rerun by hand with run-parts.sh post-create at any time.
Connections