Skip to content

[Feature]: Ability to exclude dev packages from production Docker image #1227

Open
@apgrucza

Description

@apgrucza

Is your feature request related to a problem you're trying to solve? Please describe.
The Devbox documentation says you can generate a production Docker image with the exact same tools you used for development. But a Devbox environment typically contains tools that you would not want to be present in production, e.g. Git, Make, Terraform. (Especially when using pure mode, which forces more of these types of tools to be specified in the Devbox environment.)

Describe the solution you'd like
I would like Devbox to be able to generate a "production" Dockerfile that excludes certain packages. This could be achieved by having a dev_packages attribute in devbox.json, in much the same way as package.json files have dependencies and devDependencies attributes.

  • By default, all packages should be included unless a --production flag is used. This flag would be needed on at least the devbox generate dockerfile and devbox install commands, but could be added to others too (e.g. devbox shell).
  • Ideally, Devbox itself should be excluded from Dockerfiles too. This may require a similar trick to what was done in [devcontainer] Added shellenv to dockerfile template #1036, where devbox shellenv --init-hook was used to set up the environment in the container so that Devbox does not need to be run.
  • The following could be moved out into a separate issue if necessary: A new dev_init_hooks array may also be required in devbox.json, in case people have init hooks that should not run in production. Alternatively, Devbox could pass a DEVBOX_PRODUCTION environment variable to each hook, so that the hook can decide whether or not to run. The former approach is cleaner, but the latter gives users more control over the order in which the hooks run. Perhaps both approaches should be implemented so that users can choose what's best for them.

Describe alternatives you've considered
An alternative solution would be to maintain two separate devbox.json files, one for dev and one for production, but this is not ideal because the versions specified for common packages may become out of sync.

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureNew feature or requestrfcLooking for feedback and comments

    Type

    No type

    Projects

    Status

    Request for Comment

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions