Skip to main content

Getting Started with Deploio

Deploio is a fully managed app platform where you just bring the source code of your web application and it'll take care of building and deploying it continously. Currently, the following languages are supported:

If your favorite language is missing and you would like to use Deploio, please let us know or activate the Dockerfile feature. We will add more languages based on demand.

Deploying your first app​

Deploio is available via the cockpit UI, a CLI and an API. To install and setup the CLI, refer to the documentation of nctl. You need at least version v1.1.0 for using Deploio. You can check the installed version with nctl --version.

Once nctl is setup you can create your first application. In this guide we'll be deploying one of the example apps that we provide in our deploio-examples repository.

For the most minimal example, we just need to provide the git url containing the app source code and the subpath if the app is not in the root of the repository. Feel free to fork the GitHub repository so you can make changes and see how they affect the app.

$ nctl create app go-example --git-url=https://github.com/ninech/deploio-examples --git-sub-path=go
Creating a new application
 ✓ created application "go-example" 🏗
 ✓ waiting for build to start ⏳
 ✓ building application 📦
 ✓ releasing application 🚦
 ✓ release available ⛺

Your application "go-example" is now available at:
  https://go-example.46e4146.deploio.app

After the creation has finished, you should be able to access the app:

$ curl https://go-example.46e4146.deploio.app
Hello from a Go Deploio app!

Using a private git repository​

In our example we used a public git repository that does not need any authentication for pulling the code. If your application code is hosted in a private repository, you can configure git authentication in various ways.

Builds and Releases​

Now that we have an application deployed, we can dig into the details a bit and see the lifecycle of an application. During the creation there are two essential phases:

  • Build Phase: This is triggered by any source code change.
  • Release Phase: This is triggered by either an image change resulting from a build or a config change.

Both of these are represented within the CLI with their respective commands.

# get all builds
$ nctl get builds
nctl get builds
NAME                   APPLICATION    STATUS     AGE
go-example-build-1     go-example     success    5m

# get all releases
$ nctl get releases
NAME                    BUILDNAME              APPLICATION    SIZE     REPLICAS    STATUS        AGE
saved-hawkeye-2jcvs     go-example-build-1     go-example     micro    1           available     7m

To demonstrate a new release, we can increase the replicas from 1 to 2 by issuing the nctl update app command:

$ nctl update app go-example --replicas=2
 ✓ updated Application "go-example" ⬆️
$ nctl get releases
NAME                   BUILDNAME             APPLICATION    SIZE     REPLICAS    STATUS        AGE
saved-hawkeye-2jcvs    go-example-build-1    go-example     micro    1           superseded    100m
helping-aztec-l492k    go-example-build-1    go-example     micro    2           available     6s

As you can see another release has been created with 2 replicas. This change happens immediately as the app code itself did not change and the same build can be reused. If we were to change the source a new build would be triggered and after build success we would also see a new release using the new build.

Accessing logs​

To view logs, troubleshoot issues and get an overview of the resources your app uses see Observing your App.

Configuring the app to your needs​

In our previous example we have demonstrated the most basic use-case for creating an app on Deploio. There are quite a few options, like using custom host names or setting environment variables which you can configure on a Deploio application to customize things to your needs. Please see the corresponding documentation in our "Configuration" section on the left to get more information about all possible options.

Projects​

When you first start interacting with nctl, everything you create will be scoped in your main project, which has the same name as your organization. To be able to separate different environments logically, you can create projects. Project names need to be prefixed with your organization name. So for example for the organization acme, a project could be named acme-dev. You are free to name it anything that fits the purpose, it just has to be prefixed with the organization name.

$ nctl create project acme-dev
Creating new project acme-dev for organization acme
 ✓ created project "acme-dev" 🏗
 ✓ waiting for project to be ready ⏳
 ✓ project ready 🛫

Once you have created a new project, you can switch nctl to default all commands in a project using nctl auth set-project.

$ nctl auth set-project acme-dev

After that, any command that interacts with resources will be scoped inside said project. You can also use the -p/--project flag to e.g. get apps in a specific project without changing the default. To list all apps in a project you can use -A/--all-projects flag.