Skip to main content

Getting Started with (Beta) 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. For the Beta, the following languages are supported:

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

Deploying your first app​

For the Beta, 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 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= --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:

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

$ curl
Hello from a Go 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
go-example-build-1 go-example success 5m

# get all releases
$ nctl get releases
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
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​

Logs of your app can be accessed using the nctl logs command. The logs contain anything your app outputs to stdout and stderr.

$ nctl logs app go-example
2023-06-19T14:21:32+02:00 2023/06/19 12:21:32 got request
# you can also live-tail the logs using the `-f/--follow` option
$ nctl logs app go-example -f
2023-06-19T14:21:32+02:00 2023/06/19 12:21:32 got request
2023-06-19T14:23:54+02:00 2023/06/19 12:23:54 got request
# to get more lines, use the -l/--lines flag
$ nctl logs app go-example -l 100
# to go further back in time, use the -s/--since flag
# durations can be specified using 1s (1 second), 1m (1 minute) and 1h (1 hour)
$ nctl logs app go-example -s 1h

Besides the app logs, you can also view the logs of the build process. This is very essential in finding the cause of a failed build.

$ nctl logs build go-example-build-1
# alternatively you can also use the app name to get the logs of all past builds
$ nctl logs build -a go-example

Configuring the app to your needs​

In our previous example we have demonstrated the most basic use-case for creating an app on There are quite a few options, like using custom host names or setting environment variables which you can configure on a 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.


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.