Deploying your Sisk Application

The process of deploying a Sisk application consists of publishing your project into production. Although the process is relatively simple, it is worth noting details that can be lethal to the security and stability of the deployment's infrastructure.

Ideally, you should be ready to deploy your application to the cloud, after carrying out all possible tests to have your application ready.

Publishing your app

Publishing your Sisk application or service is generating binaries ready and optimized for production. In this example, we will compile the binaries for production to run on a machine that has the .NET Runtime installed on the machine.

You will need .NET SDK installed in your machine in order to build your app, and .NET Runtime installed on the target server to run your app. You can learn how to install .NET Runtime in your Linux server here, Windows and Mac OS.

In the folder where your project is located, open a terminal and use the .NET publish command:

dotnet publish -r linux-x64 -c Release

This will generate your binaries inside bin/Release/publish/linux-x64.

Note

If your app is running using Sisk.ServiceProvider package, you should copy your service-config.json into your host server along all binaries generated by dotnet publish. You can leave the file preconfigured, with environment variables, listening ports and hosts, and additional server configurations.

The next step is to take these files to the server where your application will be hosted.

After that, give execution permissions to your binary file. In this case, let's consider that our project name is "my-app":

cd /home/htdocs
chmod +x my-app
./my-app

After running your application, check to see if it produces any error messages. If it didn't produce, it's because your application is running.

At this point, it will probably not be possible to access your application by external net ouside your server, as access rules such as Firewall have not been configured. We will consider this in the next steps.

You should have the address of the virtual host where your application is listening to. This is set manually in the application, and depends on how you are instantiating your Sisk service.

If you're not using the Sisk.ServiceProvider package, you should find it where you defined your HttpServer instance:

HttpServer server = HttpServer.Emit(5000, out HttpServerConfiguration config, out var host, out var router);
// sisk should listen on http://localhost:5000/

Associating an ListeningHost manually:

config.ListeningHosts.Add(new ListeningHost("https://localhost:5000/", router));

Or if you're using the Sisk.ServiceProvider package, in your service-config.json:

{
  "Server": { },
  "ListeningHost": {
    "Ports": [
      "http://localhost:5000/"
    ]
  }
}

From this, we can create a reverse proxy to listen to your service and make the traffic available over the open network.

Proxying your application

Proxying your service means not directly exposing your Sisk service to an external network. This practice is very common for server deployments because:

Allows you to associate an SSL certificate in your application;
Create access rules before accessing the service and avoid overloads;
Control bandwidth and request limits;
Separate load-balancers for your application;
Prevent security damage to failing infrastructure.

You can serve your application through a reverse proxy like Nginx or Apache, or you can use an http-over-dns tunnel like Cloudflared.

Also, remember to correctly resolve your proxy's forwarding headers to obtain your client's information, such as IP address and host, through forwarding resolvers.

The next step after creating your tunnel, firewall configuration and having your application running, is to create a service for your application.

Note

Using SSL certificates directly in the Sisk service on non-Windows systems is not possible. This is a point of the implementation of HttpListener, which is the central module for how HTTP queue management is done in Sisk, and this implementation varies from operating system to operating system. You can use SSL in your Sisk service if you associate a certificate with the virtual host with IIS. For other systems, using a reverse proxy is highly recommended.

Creating an service

Creating a service will make your application always available, even after restarting your server instance or a non-recoverable crash.

In this simple tutorial, we will use the content from the previous tutorial as a showcase to keep your service always active.

Access the folder where the service configuration files are located:
```
cd /etc/systemd/system
```

Create your my-app.service file and include the contents:

[Unit]
Description=<description about your app>

[Service]
# set the user which will launch the service on
User=<user which will launch the service>

# the ExecStart path is not relative to WorkingDirectory.
# set it as the full path to the executeable file
WorkingDirectory=/home/htdocs
ExecStart=/home/htdocs/my-app

# set the service to always restart on crash
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Restart your service manager module:
```
sudo systemctl daemon-reload
```
Start your new created service from the name of the file you set and check if they are running:
```
sudo systemctl start my-app
sudo systemctl status my-app
```
Now if your app is running ("Active: active"), enable your service to keep run after an system reboot:
```
sudo systemctl enable my-app
```

Now you're ready to go and present your Sisk application to everyone.

Table of Contents

Deploying your Sisk Application

Publishing your app

Note

Proxying your application

Note

Creating an service