Skip to content


What is a Diploi Deployment?

In Diploi, a deployment is a full instance of your application, including databases and other services. It also includes storage and current code changes you are working on.

Deployment can be divided into dynamic development deployments and built deployments such as testing / staging / production. The main difference is that development deployments will have persistent storage for your code so that code changes will remain even if the service restarts etc. For build deployments the containers will start fresh on every restart and run the built production version of your application. How this works can in part depend on how the project template works so make sure to check the project template documentation.

Deployment Types

There are three commonly used deployment types:

  1. Production: For the live version of your application accessible to end-users. It involves creating a build from your application’s source code. Focuses on stability, performance, and scalability.

  2. Staging: Staging deployments are used for testing and quality assurance purposes. They closely resemble the production environment but are separate from the live application. Staging deployments usually create a build from your application’s source code. Allows you to test changes before deploying them to production.

  3. Development: The development deployment type is primarily used for remote development. It offers a flexible environment for iterative development and debugging. In this case, the code is cloned directly from Git without going through the build process. Development deployments often utilize hot module reloading (HMR) or similar techniques to enable quick code updates without restarting the entire server.

It’s important to note that the available deployment types are defined by the template, so the actual types provided may vary from the standard list mentioned above.

By choosing the appropriate deployment type, you can ensure that your application is properly deployed, tested, and optimized for the specific stage of development or production environment it is intended for.


Diploi will by default create a public endpoint for your application and generate an SSL certificate. If you want to use your own domain please see the Custom domain guide.

Connecting using SSH

Once you have created a deployment, look for the “Connect via SSH” command on the “Overview” tab. This command can be copied to your terminal of choice to open an SSH connection to the deployment.

Remote Development

Diploi supports remote development by using the remote development capabilities of eg. Visual Studio Code, but any editor that support editing using an SSH connection will work.

For more details, please see the Remote Development guide.

Status and Logs

After a deployment is started you can check it’s status from the Deployments Overview page. You can check CPU load and Diploi has a color indication of the overall state of the deployment

  • Green – the deployment is working correctly
  • Yellow – there is some issue but the deployment still runs
  • Red – there is some bigger issue that needs to be addressed

At the bottom of the page is a status tree that gives a more detailed view of the current state.

  • Storage – Shows the state of persistant storage
  • Builds – Indicates the state of container images required to run your application. If some image is being built you can follow the progress here. There is also a link to GitHub Actions so you can debug possible build issues there.
  • Containers – Lists all containers running in the cluster
  • Services – Show the status of services within your application. The entries here and how they work depend on the template you are running. Depending on the template you might even be able to add/remove items to this list.

Deleting a Deployment

When you don’t need a deployment anymore, you should press the Delete deployment button on last on the Options tab. Please be aware that this will permanently delete any persistent storage (such as code, databases etc.) associated with the instance. You don’t need to shut down the deployment before deleting.