Deploying to Hop
When deploying to Hop, we use a tool called Nixpacks to automatically infer your environment and build a container image for your application. However, you can also use your own
Dockerfile to build your image. If we detect a
Dockerfile in your project directory, we’ll use that instead of Nixpacks.
There are various ways to deploy applications to Hop.
When creating a deployment, you are able to configure various options to customize how your application runs. All of these options can be updated after the deployment is created, too.
The resources section allows you to configure the compute resources your that each container which runs within your deployment will be allocated (vCPU, memory and disk space). Hop has 4 presets which you can choose from to quickly set your resources. You can also configure the resources manually by selecting Custom Resources and setting the values yourself.
If you select the Add volume to deployment checkbox, you’re able to configure the size and mount path of the volume that will be attached to your deployment. Please note that by selecting this option, your deployment will become Stateful. Stateful deployments may currently only run one container at a time.
You can choose between two file systems for your volume:
xfs. In general, XFS is better at handling large files, while Ext4 is more is more performant when handling a lot of small files. XFS is usually recommended for running databases. Please see this article by Red Hat for more information.
You can add environment variables through our GUI, plain text editor and JSON editor. Once set, your environment variables will be made available to your application during build time and runtime.
You can also point environment variables to project secrets. If using the GUI, you can select a secret from the dropdown. If using a text editor, API or CLI, you can use the following syntax:
You should only modify these options if you understand how the Dockerfile is built for the image you’re trying to deploy.
You cannot use Ephemeral containers with Stateful deployments (volumes).
Enable Use ephemeral containers to run your deployment with ephemeral containers. Ephemeral containers are deleted immediately once they exit. This is useful for running one-off tasks such as database migrations. Your deployment can run an unlimited number of ephemeral containers at a time - you can use our API to create them dynamically.
Entrypoint & CMD Override
You can override the entrypoint or CMD of your containers within the scope of a deployment.
The entrypoint is the base command that is run when the container starts. The CMD is the default arguments to pass to the entrypoint. An entrypoint is always needed, and if not provided, is inherited from the base image.