Sign In
Sign In

How to Install Mattermost on Ubuntu

How to Install Mattermost on Ubuntu
Hostman Team
Technical writer
Servers
14.11.2024
Reading time: 8 min

Mattermost is a messaging and collaboration platform that can be installed on self-hosted servers or in the cloud. It serves as an alternative to messengers like Slack and Rocket.Chat.

In this guide, we will review the Free plan, which includes unlimited message history and group calls (for more details on pricing plans, see the official website). Mattermost clients are available for mobile (iOS, Android) and desktop (Windows, Linux, Mac), and there’s also a browser-based version. Only the Self-Hosted Mattermost version is available under the Free plan.

We will go through the installation on Ubuntu. Other installation methods (including a Docker image) are available in the official docs.

And if you’re looking for a reliable, high-performance, and budget-friendly solution for your workflows, Hostman has you covered with Linux VPS Hosting options, including Debian VPS, Ubuntu VPS, and VPS CentOS.

Technical Requirements

For 1,000 users, a minimum configuration of 1 CPU, 2 GB RAM, and PostgreSQL v11+ or MySQL 8.0.12+ is required.

We will use the following resources:

  • For PostgreSQL 16: We'll provision a DBaaS with 1 CPU, 1 GB RAM, and 20 GB of disk space.
  • For Mattermost: We'll provision a server running Ubuntu with 2 CPUs, 2 GB RAM, and 60 GB of disk space.

We will also need to restrict access to the database. We will do it by setting up a private network in Hostman.

Environment Setup

Creating a Private Network

To restrict database access, we can use Firewall, but in this setup, all services will be within the same network

Important: Services must be located in the same region to operate within a single network.

Image4

Database

We'll provision the database as a service with the following configuration: 1 CPU, 1 GB RAM, and 20 GB of disk space, hosted in Poland.

Image3

While creating the database, in the Network section, select the No external IP option and the network created in the previous step.

Image17

The default database is default_db, and the user is gen_user.

Server for Mattermost

Next, we need to set up a server for Mattermost and Nginx. This server will run Ubuntu 22.04 and will be hosted in Poland.

Image13

For the configuration, we need at least 2 CPUs, 2 GB RAM, and 50 GB of disk space, so we will choose a close enough plan:

Image6

You can also select the exact parameters (2 CPUs, 2 GB RAM, 50 GB) by using the Custom tab, but it will be more expensive.

As with the PostgreSQL setup, select the previously created network in the Network step.

Image9

Create the server.

Domain

We will also need a domain to obtain a TLS certificate. In this guide, we will use example.com.

You can add your domain in the Domains → Add domain section in the Hostman control panel. 

Image1

Ensure the domain is linked to the server. You can verify this in the Network section. If the domain is not listed next to the IP address, it can be added manually through the Set Up Reverse Zone option.

Image11

Installing Mattermost

Now that the environment is ready, we can proceed with installing Mattermost. To begin, we’ll connect to the repository at deb.packages.mattermost.com/repo-setup.sh:

curl -o- https://deb.packages.mattermost.com/repo-setup.sh | sudo bash -s mattermost

Here, the mattermost argument is passed to sudo bash -s mattermost to add only the Mattermost repository. If no argument is provided, the script’s default all argument will add repositories for Mattermost, Nginx, PostgreSQL, and Certbot.

Installing the Service

The Mattermost service will install to /opt/mattermost, with a mattermost user and group created automatically:

sudo apt update
sudo apt install mattermost -y

After installation, create a config.json file with the necessary permissions, based on the config.defaults.json file. Read and write access should be granted only to the owner (in this case, the mattermost user):

sudo install -C -m 600 -o mattermost -g mattermost /opt/mattermost/config/config.defaults.json /opt/mattermost/config/config.json

Configuring Mattermost

Open config.json to fill in key parameters:

sudo nano /opt/mattermost/config/config.json

Set the following:

  • SiteURL: Enter the created domain with the https protocol in the ServiceSettings block, which will be linked with an SSL certificate later.

"ServiceSettings": {
    "SiteURL": "https://example.com",
    "WebsocketURL": ""
}
  • DriverName: Ensure this is set to postgres in the SqlSettings block.

  • DataSource: Provide the username, password, host, and database name in the connection link in the SqlSettings block.

Image16

Other configurations are optional for the initial launch and can be modified later in the Mattermost administrative console.

Starting Mattermost

Start the Mattermost service:

sudo systemctl start mattermost

To verify that Mattermost started successfully:

sudo systemctl status mattermost.service

Image15

And verify it is accessible on port 8065.

Image5

If the site doesn’t open, check the firewall settings. You can also verify local access to port 8065 directly from the server:

curl -v localhost:8065

Enabling Auto-Start

Finally, enable Mattermost to start automatically on boot:

sudo systemctl enable mattermost.service

With these steps, Mattermost should be up and running and ready for further configuration and usage.

Setting Up Nginx as a Reverse Proxy for Mattermost

We will set up Nginx as a reverse proxy to prevent direct access on port 8065, which will be closed later via firewall.

Install Nginx:

sudo apt install nginx

Create the Nginx Configuration File:

sudo nano /etc/nginx/sites-available/mattermost

Nginx Configuration for Mattermost:

Add the following configuration, replacing example.com with your actual domain name. This configuration proxies both HTTP and WebSocket protocols.

upstream backend {
  server 127.0.0.1:8065;
  keepalive 32;
}

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off;

server {
  listen 80;
  server_name example.com;

  location ~ /api/v[0-9]+/(users/)?websocket$ {
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    client_max_body_size 50M;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Frame-Options SAMEORIGIN;
    proxy_buffers 256 16k;
    proxy_buffer_size 16k;
    client_body_timeout 60;
    send_timeout 300;
    lingering_timeout 5;
    proxy_connect_timeout 90;
    proxy_send_timeout 300;
    proxy_read_timeout 90s;
    proxy_pass http://backend;
  }

  location / {
    client_max_body_size 50M;
    proxy_set_header Connection "";
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Frame-Options SAMEORIGIN;
    proxy_buffers 256 16k;
    proxy_buffer_size 16k;
    proxy_read_timeout 600s;
    proxy_cache mattermost_cache;
    proxy_cache_revalidate on;
    proxy_cache_min_uses 2;
    proxy_cache_use_stale timeout;
    proxy_cache_lock on;
    proxy_http_version 1.1;
    proxy_pass http://backend;
  }
}

Create a symbolic link to enable the Mattermost configuration:

sudo ln -s /etc/nginx/sites-available/mattermost /etc/nginx/sites-enabled/mattermost

Remove the default configuration:

sudo rm -f /etc/nginx/sites-enabled/default

Restart the Nginx service to apply the changes:

sudo service nginx restart

Setting Up SSL with Let’s Encrypt:

Use Certbot to obtain an SSL certificate for your domain. Certbot will automatically configure Nginx for HTTPS.

sudo apt install python3-certbot-nginx && certbot

Certbot will prompt you to enter your email and domain name and then add the certificate to your domain.

After installing the certificate, Certbot will update the Nginx configuration file to include:

  • A listen directive for handling requests on port 443 (HTTPS)
  • SSL keys and configuration directives
  • A redirect from HTTP to HTTPS

With this setup complete, Mattermost should be accessible over HTTPS on your domain. Nginx will handle HTTP to HTTPS redirection, and secure connections will be established using the SSL certificate from Let’s Encrypt.

Setting Up Firewall

Now, go to your Mattermost server page in the Hostman control panel. Open the Network tab to add firewall rules.

Image2

We will allow incoming TCP requests to ports 22 for SSH access, and 80 and 443 for TCP

To collect metrics on the server dashboard, port 10050 also needs to be open; the list of IP addresses that require access to this port can be found in /etc/zabbix/zabbix_agentd.conf.

Image14

First Launch

Now you can Mattermost at https://your_domain/.

Image8

You can create an account and workspace directly in the browser.

Image7

After installation and on the first login, you may encounter an issue with WebSocket connectivity.

Image10

To solve it, check the configuration. You can do it in the System Console.

Image12

Out-of-the-box features include calls, playbooks, a plugin marketplace, and GitLab authentication. Additionally, Mattermost offers excellent documentation.

Conclusion

In this guide, we deployed the free self-hosted version of Mattermost on Hostman servers with a dedicated database accessible only from the internal network. Keep in mind that we allocated the server resources for a general scenario, so you may need additional resources. It’s advisable not to skip load testing! 

Servers
14.11.2024
Reading time: 8 min

Similar

Servers

Deploying and Configuring Keycloak

If you have a web application and you don’t want to write your own authentication from scratch, most likely, Keycloak will come in handy. This is a ready-made user management system that can do everything: logins, roles, tokens, social networks, and even SSO out of the box. In this article, we’ll look at how to deploy Keycloak on a Hostman server and configure authentication for your applications. What Keycloak Is and What It Does Keycloak is a service that takes over all the work with authorization and authentication. Instead of building your own system of logins, passwords, email confirmations, roles, and tokens, you just connect Keycloak and get everything you need. Keycloak functions as an independent service: it has a control panel, a REST API, integration with external systems, and clients for popular languages and frameworks. In essence, Keycloak becomes the central authorization hub in the project: users authorize through it, receive tokens, and then get into your applications. Key scenarios where Keycloak shows itself best: Single Sign-On (SSO) — one login for all your services. OAuth2 and OpenID Connect — ready-made implementation of standards. Roles and groups — determine which actions are available to a user. Social logins — login through Google, GitHub, etc. User management — creation, ban, password reset, email confirmation. Integration with any frontends and backends — Java, Python, Node.js, React, Angular. Keycloak helps not only to quickly launch login via username and password but also to scale access: from one landing page to dozens of microservices with different permissions. Installing Keycloak You can deploy Keycloak anywhere, from a home server to Kubernetes. But if you need a quick start without unnecessary complications, a regular VPS is suitable. Let’s see how to install Keycloak in Hostman conveniently, quickly, and inexpensively. What you will need: A Hostman account A cloud server (VPS) on Ubuntu 22.04 Installed Docker and Docker Compose (we’ll show below) Step 1. Create a server in Hostman Go to the control panel → Cloud servers. Click Create. Select the Ubuntu 22.04 image. Set the parameters (CPU, RAM, disk); the minimum configuration is enough for a test. Launch the server and connect to it via SSH. Step 2. Install Docker and Docker Compose This can be done in two commands: curl -fsSL https://get.docker.com -o get-docker.sh   sh get-docker.sh  Wait until the commands finish executing. Step 3. Create a Docker Compose file Create a folder for the project and a configuration file: mkdir keycloak && cd keycloak   nano docker-compose.yml  Insert the following content: services: keycloak: image: quay.io/keycloak/keycloak:26.3.2 command: start-dev environment: - KEYCLOAK_ADMIN=admin - KEYCLOAK_ADMIN_PASSWORD=admin ports: - "8080:8080" restart: always Save with the key combination Ctrl+O, then Enter to confirm. Close the editor with the combination Ctrl+X. Step 4. Start Keycloak Use the command: docker compose up -d In a minute, Keycloak will be available at: http://<your_IP>:8080 Step 5. Disable the HTTPS requirement (only for testing) By default, Keycloak requires HTTPS even in dev mode, which may result in the message “HTTPS required” when opening. To disable this behavior only in the test environment, run the following commands inside the Keycloak container: docker exec -it keycloak-keycloak-1 /opt/keycloak/bin/kcadm.sh config credentials --server http://localhost:8080 --realm master --user admin --password admin   docker exec -it keycloak-keycloak-1 /opt/keycloak/bin/kcadm.sh update realms/master -s sslRequired=NONE  After this, you can refresh the page; the HTTPS message will disappear. Now you can log in to the panel with the username and password admin. Basic Keycloak Configuration After successfully launching the container with Keycloak, you will get the admin panel at the address: http://<your-server>:8080/admin   This is where all configuration takes place: from creating realms to connecting clients, roles, and users. Realms In Keycloak, everything starts with a realm. It’s like a separate “world” with its own database of users, security settings, and applications. Imagine you are building a platform with two projects: an internal portal for employees and a website for clients. Each has its own users, its own roles, its own login settings. To avoid storing everything together, you create two realms: staff and clients. They are completely isolated from each other: logins, rules, login pages, and even password policies can be configured differently. A realm is a way to maintain order in the system and not mix users from different applications. Let’s create our own realm. To do this, go to the Manage realms tab (1) in the admin panel and click the Create realm button (2). Navigation to creating a realm in Keycloak: the “Manage realms” tab and the “Create realm” button Next, enter the realm name and click the Create button. Realm creation form: entering the name and confirming by clicking “Create” Go back to the Manage realms tab and click on the new realm; now it is selected by default. If you are testing Keycloak, disable the SSL certificate requirement for the new realm; it is not required in the test environment. Use: docker exec -it keycloak-keycloak-1 /opt/keycloak/bin/kcadm.sh update realms/<NEW_REALM_NAME> -s sslRequired=NONE   Users and Roles Users are people or services that will log into your applications through Keycloak. Each has its own username, password, and set of permissions. Users without assigned roles do not get access to any functions. To determine what they can and cannot do, roles are assigned to them. Roles are labels like “admin,” “manager,” “viewer.” They don’t do anything by themselves, but they let the application know: “this person is an admin, they can delete; and that one can only view.” Create your own role. To do this, go to the Realm roles tab (1) and click the Create role button (2). Navigation to the roles section: the “Realm roles” tab and the “Create role” button for creating a new role Enter the role name and click the Save button. Creating a role Now let’s try creating a user. Go to the Users tab and click the Add user button. Be sure to enter a username, and optionally an email, first name, and last name. Click Create. Creating a user: specify the parameters and save with the “Create” button Assign the new user a password for login. To do this, on the opened page, go to the Credentials tab (1), click the Set password button (2), set the password and repeat it. Leave the Temporary parameter enabled so that the new user changes their password after their first login into the system. Assigning login credentials: open the “Credentials” tab and enter the password of the new user Now assign the new user a role. In the same section, go to the Role mapping tab (1), click the Assign role button (2) → Realm roles (3). Assigning a role: open the “Role mapping” tab and select the desired role via “Assign role” → “Realm roles” Select the role and click Assign. Selecting a role from the list and confirming the assignment with the “Assign” button Now the role is assigned to the user. Clients Clients in Keycloak are applications that connect to the authorization system. Through them, the user logs into the service, and Keycloak verifies their identity and rights. Without a client, the system will not understand where the user came from, where to return them after login, and what permissions can be given. For each client, you can configure the login method: by username and password, through social networks, with two-factor authentication, or with tokens. You can allow or deny specific roles. You can specify where to redirect the user after successful login and after logout. Important: the same user can log into different clients. For example, in the frontend client, they log in as a regular user, and in the admin-panel client as a moderator. This is convenient when the application has multiple interfaces with different access levels. Authorization begins with the client. The application redirects the user to Keycloak. It verifies their data and returns them with a token. And the application uses this token to find out who it is dealing with and what is allowed for them. Create a test client. Go to the Clients tab and click the Create client button. Enter the client name in the Client ID field. At the Login settings step, in the Valid redirect URIs field, enter valid paths where the user can be redirected after authorization. For testing, you can leave an asterisk *. The other values can be left by default. Screen after creating a client in Keycloak Configuring Authorization for Applications Keycloak can be connected to almost any application: a frontend in React, a backend in Flask, a native desktop, or a mobile app. Keycloak itself implements standard protocols OAuth 2.0 and OpenID Connect, which means the application does not depend on the platform: if it supports authorization via the standard, it can work with Keycloak. The connection process is always roughly the same. The application redirects the user to Keycloak. It requests their login and password and returns a code. The application exchanges the code for a token and starts working with it. From that moment, the user is considered authorized. You can check their rights, roles, and accesses. On the Keycloak side, the application is set up as a client, for which authorization scenarios and access restrictions are defined in the interface. All these settings depend on the type of application and its capabilities. For example, if the user is writing a regular website, the standard flow will be enough. And if you want to authorize an IoT device, most likely, you will need to use the client credentials flow without user participation. Here's an example of configuring environment variables in the .env file for connecting to Keycloak. In your case, you would enter the IP address or domain of your server instead of the one shown there, and change the realm to the one you created. # Keycloak configuration KEYCLOAK_URL=http://166.1.227.100:8080 KEYCLOAK_REALM=master KEYCLOAK_CLIENT_ID=test-client KEYCLOAK_CLIENT_SECRET=your-client-secret KEYCLOAK_ADMIN_USERNAME=admin KEYCLOAK_ADMIN_PASSWORD=admin # Server configuration PORT=3000 SERVER_URL=http://166.1.227.100:3000 SESSION_SECRET=your-session-secret-change-this # Application URLs (must match Keycloak client configuration) APP_URL=http://166.1.227.100:3000 VALID_REDIRECT_URIS=http://166.1.227.100:3000/*,http://166.1.227.100:3000/oauth2/callback/* Integration with External Services Keycloak can be used not only for your own projects but also for logging into third-party services—for example, GitLab, Jenkins, or Grafana. This is especially convenient if you want to implement single sign-on (SSO) for the team. Documentation for integrating any service with Keycloak can be found publicly. As an example, let’s look at setting up authorization through Keycloak for GitLab. For this, you will need docker-compose and basic configuration in the control panel. Note that in this case, external services require the mandatory presence of an SSL certificate so that Keycloak can ensure secure login. For this, you will need your own domain. Here, it will be convenient to create two additional subdomains, for GitLab and for Keycloak, respectively. If GitLab is already installed, you can add the settings manually. But it’s simpler to deploy everything together right away. Below is an example docker-compose.yml that launches Keycloak and GitLab, already configured to work with each other. Don’t forget to put your domain instead of example.com. version: "3.9" services: traefik: image: traefik:v3.1 container_name: traefik command: - "--api.dashboard=true" - "--providers.docker=true" - "--entrypoints.web.address=:80" - "--entrypoints.websecure.address=:443" - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true" - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - "--certificatesresolvers.letsencrypt.acme.email=admin@example.com" - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports: - "80:80" - "443:443" volumes: - "./letsencrypt:/letsencrypt" - "/var/run/docker.sock:/var/run/docker.sock:ro" restart: unless-stopped networks: - app-network gitlab: image: gitlab/gitlab-ce:latest container_name: gitlab hostname: gitlab.example.com volumes: - gitlab-config:/etc/gitlab - gitlab-logs:/var/log/gitlab - gitlab-data:/var/opt/gitlab restart: unless-stopped environment: GITLAB_OMNIBUS_CONFIG: | external_url 'https://gitlab.example.com' nginx['listen_https'] = false nginx['listen_port'] = 80 gitlab_rails['omniauth_enabled'] = true gitlab_rails['omniauth_allow_single_sign_on'] = ['openid_connect'] gitlab_rails['omniauth_auto_link_user'] = ['openid_connect'] gitlab_rails['omniauth_block_auto_created_users'] = false gitlab_rails['omniauth_providers'] = [ { name: "openid_connect", label: "Keycloak", args: { name: "openid_connect", scope: ["openid", "profile", "email"], response_type: "code", issuer: "https://keycloak.example.com/realms/master", discovery: true, client_auth_method: "query", uid_field: "preferred_username", client_options: { identifier: "gitlab", secret: "secret", redirect_uri: "https://gitlab.example.com/users/auth/openid_connect/callback" } } } ] labels: - "traefik.enable=true" - "traefik.http.routers.gitlab.rule=Host(`gitlab.example.com`)" - "traefik.http.routers.gitlab.entrypoints=websecure" - "traefik.http.routers.gitlab.tls.certresolver=letsencrypt" - "traefik.http.services.gitlab.loadbalancer.server.port=80" networks: - app-network keycloak: image: quay.io/keycloak/keycloak:26.3.2 container_name: keycloak command: start-dev environment: KC_HOSTNAME: https://keycloak.example.com KC_HOSTNAME_STRICT: false KC_HOSTNAME_HTTPS: true KC_PROXY: edge KC_HTTP_ENABLED: true KEYCLOAK_ADMIN: admin KEYCLOAK_ADMIN_PASSWORD: admin labels: - "traefik.enable=true" - "traefik.http.routers.keycloak.rule=Host(`keycloak.example.com`)" - "traefik.http.routers.keycloak.entrypoints=websecure" - "traefik.http.routers.keycloak.tls.certresolver=letsencrypt" - "traefik.http.services.keycloak.loadbalancer.server.port=8080" networks: - app-network volumes: gitlab-config: gitlab-logs: gitlab-data: networks: app-network: driver: bridge In the project, Traefik is used as a reverse proxy. It will automatically issue free Let’s Encrypt SSL certificates for the subdomains. Launch the project: docker compose up -d In the Keycloak admin panel, create a client gitlab, where you specify: Root URL — the GitLab domain with the https protocol. For example, https://gitlab.example.com. Valid redirect URIs — the GitLab domain with the https protocol and all possible paths under this domain. For example, https://gitlab.example.com/*. The default realm is master. If desired, you can create a separate realm. Users for GitLab and other services are created manually through the Keycloak admin panel. After loading GitLab, go to the login page at the domain belonging to GitLab. The service will offer to log in via Keycloak: GitLab login screen with an available option to log in via Keycloak After successful authorization via Keycloak, the editing panel of the new user created after authorization will open. GitLab new user settings window after authorization via Keycloak Troubleshooting Common Issues Sometimes errors occur when deploying and configuring Keycloak, both in the panel itself and during integration with other services. Below we’ve collected common symptoms, causes, and solutions so you can quickly fix the problem and continue setup. Symptom Problem Solution “HTTPS required” in the browser or logs Keycloak требует HTTPS даже в dev-режиме Keycloak requires HTTPS even in dev mode: docker exec -it keycloak-keycloak-1 bash./kcadm.sh config credentials --server http://localhost:8080 --realm master --user admin --password admin ./kcadm.sh update realms/master -s sslRequired=NONE Keycloak UI loads endlessly Error due to incorrect KC_HOSTNAME or CORS Make sure the KC_HOSTNAME variable is not set or matches the address where you are opening Keycloak Keycloak does not save sessions/settings Launched without volume, state is not saved Add a volume in docker-compose.yml:- keycloak_data:/opt/keycloak/data Error Web Crypto API is not available React application is running in an environment without HTTPS or in an old browser Run via HTTPS or in a modern browser. On a dev server, use localhost A 'Keycloak' instance can only be initialized once Multiple Keycloak initializations in React Make sure initialization happens only once, for example, in a separate keycloak.js file, not in each component Ssl connect returned=1 errno=0 ... in GitLab GitLab requires HTTPS, but Keycloak is running over HTTP Temporarily disable SSL requirement in Keycloak (dev only), or configure HTTPS with a self-signed or Let’s Encrypt certificate After login, the user is not created in GitLab Automatic user creation disabled in GitLab Make sure the parameters are set:omniauth_auto_link_user = ['openid_connect'] и omniauth_block_auto_created_users = false  The login button via Keycloak does not appear Error in omniauth_providers or issuer Check client_id, issuer, and redirect_uri in the GitLab configuration. They must exactly match the client in Keycloak Keycloak does not start Old docker-compose file or wrong image version Make sure you are using the current image (for example, quay.io/keycloak/keycloak:26.3.2) and the start-dev startup command Conclusion If you are creating a web application and want to quickly launch authorization, Keycloak becomes an excellent solution. It eliminates routine tasks: logins, roles, sessions, social networks, access rights—everything is available right away. And if you’re looking for a reliable, high-performance, and budget-friendly solution for your workflows, Hostman has you covered with Linux VPS Hosting options, including Debian VPS, Ubuntu VPS, and VPS CentOS. We covered how to deploy Keycloak on a server, configure the basic panel, connect React and Express applications, and integrate a third-party service like GitLab. This is a universal approach: once you configure Keycloak, you can add new services to it in just minutes and manage access from a single panel. This approach saves time, simplifies maintenance, reduces risks, and makes the system more secure. And most importantly, you no longer waste effort reinventing your own authorization.
05 September 2025 · 16 min to read
Ubuntu

How to Install VNC on Ubuntu

If you need to interact with a remote server through a graphical interface, you can use VNC technology.Through a network, users can connect remotely to a server using VNC (Virtual Network Computing). It employs the RFB protocol to send screen images and input data from different devices (such keyboards and mice) and runs on a client-server architecture. Ubuntu, Windows, macOS, and other operating systems are among those that VNC supports. The ability to connect several users at once is another benefit of VNC, which can be helpful for group tasks or training sessions. And if you’re looking for a reliable, high-performance, and budget-friendly solution for your workflows, Hostman has you covered with Linux VPS Hosting options, including Debian VPS, Ubuntu VPS, and VPS CentOS. In this guide, we will describe how to install VNC on Ubuntu, using a Hostman cloud server with Ubuntu 22.04 as an example. Finished installation of VNC on Ubuntu Step 1: Preparing to Install VNC Before starting the installation process on both the server and the local machine, there are a few prerequisites to review.  Here is a list of what you’ll need to complete the installation: A Server Running Ubuntu 22.04. In this guide, we will use a cloud server from Hostman with minimal hardware configuration. Hostman's plan selection in admin panel A User with sudo Privileges. You should perform the installation as a regular user with administrative privileges. Select a Graphical Interface. You’ll need to choose a desktop environment that you will use to interact with the remote server after installing the system on both the server and the local machine. A Computer with a VNC Client Installed.  At the moment, the console is the sole method of communication with a rented server running Ubuntu 22.04. You must install a desktop environment and VNC on the server in order to enable remote management through a graphical interface. The desktop environments and VNC servers that are compatible with Ubuntu servers are listed below. VNC Servers: TightVNC Server. One of the most popular VNC servers for Ubuntu. It is easy to set up and offers good performance. RealVNC Server. RealVNC provides a commercial solution for remote access to servers across various Linux distributions, including Ubuntu, Debian, Fedora, Arch Linux, and others. Desktop Environments: Xfce. A lightweight and fast desktop environment, ideal for remote sessions over VNC. It uses fewer resources than heavier desktop environments, making it an excellent choice for servers and virtual machines. GNOME. The default Ubuntu desktop environment, offering a modern and user-friendly interface. It can be used with VNC but will consume more resources than Xfce. KDE Plasma. Another popular desktop environment that provides a wide range of features and a beautiful design. The choice of VNC server and desktop environment depends on the user’s specific needs and available resources. TightVNC and Xfce are excellent options for stable remote sessions on Ubuntu, as they do not require high resources. In the next step, we will describe how to install them on the server in detail. Step 2: Installing the Desktop Environment and VNC Server To install the VNC server on Ubuntu along with the desktop environment, connect to the server and log in as a regular user with administrative rights. Update the Package List  After logging into the server, run the following command to update the packages from the connected repositories: sudo apt update Install the Desktop Environment  Next, install the previously selected desktop environment. To install Xfce, enter: sudo apt install xfce4 xfce4-goodies Here, the first package provides the basic Xfce desktop environment, while the second includes additional applications and plugins for Xfce, which are optional. Install the TightVNC Server  To install TightVNC, enter: sudo apt install tightvncserver Start the VNC Server  Once the installation is complete, initialize the VNC server by typing: vncserver This command creates a new VNC session with a specific session number, such as :1 for the first session, :2 for the second, and so on. This session number corresponds to a display port (for example, port 5901 corresponds to :1). This allows multiple VNC sessions to run on the same machine, each using a different display port. This command will ask you to create a password during the initial setup, which is necessary for users to access the server's graphical user interface. Don't forget to verify your password to run VNC on Ubuntu Set the View-Only Password (Optional)  After setting the main password, you’ll be prompted to set a password for view-only mode. View-only mode allows users to view the remote desktop without making any changes, which is helpful for demonstrations or when limited access is needed. If you need to change the passwords set above, use the following command: vncpasswd Now you have a VNC session. VNC on Ubuntu is running In the next step, we will set up VNC to launch the Ubuntu server with the installed desktop environment. Step 3: Configuring the VNC Server The VNC server needs to know which desktop environment it should connect to. To set this up, we’ll need to edit a specific configuration file. Stop Active VNC Instances  Before making any configurations, stop any active VNC server instances. In this guide, we’ll stop the instance running on display port 5901. To do this, enter: vncserver -kill :1 Simple command to stop VNC running on Ubuntu Here, :1 is the session number associated with display port 5901, which we want to stop. Create a Backup of the Configuration File  Before editing, it’s a good idea to back up the original configuration file. Run: mv ~/.vnc/xstartup ~/.vnc/xstartup.bak Edit the Configuration File  Now, open the configuration file in a text editor: nano ~/.vnc/xstartup Replace the contents with the following: #!/bin/bashxrdb $HOME/.Xresourcesstartxfce4 & #!/bin/bash: This line is called a "shebang," and it specifies that the script should be executed using the Bash shell. xrdb $HOME/.Xresources: This line reads settings from the .Xresources file, where desktop preferences like colors, fonts, cursors, and keyboard options are stored. startxfce4 &: This line starts the Xfce desktop environment on the server. Make the Configuration File Executable To allow the configuration file to be executed, use: chmod +x ~/.vnc/xstartup Start the VNC Server with Localhost Restriction Now that the configuration is updated, start the VNC server with the following command: vncserver -localhost The -localhost option restricts connections to the VNC server to the local host (the server itself), preventing remote connections from other machines. You will still be able to connect from your computer, as we’ll set up an SSH tunnel between it and the server. These connections will also be treated as local by the VNC server. The VNC server configuration is now complete. Step 4: Installing the VNC Client and Connecting to the Server Now, let’s proceed with installing a VNC client. In this example, we’ll install the client on a Windows 11 computer. Several VNC clients support different operating systems. Here are a few options:  RealVNC Viewer. The official client from RealVNC, compatible with Windows, macOS, and Linux. TightVNC Viewer. A free and straightforward VNC client that supports Windows and Linux. UltraVNC. Another free VNC client for Windows with advanced remote management features. For this guide, we’ll use the free TightVNC Viewer. Download and Install TightVNC Viewer Visit the official TightVNC website, download the installer, and run it. Download VNC from official website In the installation window, click Next and accept the license agreement. Then, select the custom installation mode and disable the VNC server installation, as shown in the image below. This is what you need to install Click Next twice and complete the installation of the VNC client on your local machine. Set Up an SSH Tunnel for Secure Connection To encrypt your remote access to the VNC server, use SSH to create a secure tunnel. On your Windows 11 computer, open PowerShell and enter the following command: ssh -L 56789:localhost:5901 -C -N -l username server_IP_address Make sure that OpenSSH is installed on your local machine; if not, refer to Microsoft’s documentation to install it. This command configures an SSH tunnel that forwards the connection from your local computer to the remote server over a secure connection, making VNC believe the connection originates from the server itself. Here’s a breakdown of the flags used: -L sets up SSH port forwarding, redirecting the local computer’s port to the specified host and server port. Here, we choose port 56789 because it is not bound to any service. -C enables compression of data before transmitting over SSH. -N tells SSH not to execute any commands after establishing the connection. -l specifies the username for connecting to the server. Connect with TightVNC Viewer After creating the SSH tunnel, open the TightVNC Viewer and enter the following in the connection field: localhost:56789 You’ll be prompted to enter the password created during the initial setup of the VNC server. Once you enter the password, you’ll be connected to the VNC server, and the Xfce desktop environment should appear. Stop the SSH Tunnel To close the SSH tunnel, return to the PowerShell or command line on your local computer and press CTRL+C. You found out how to install VNC on Ubuntu Conclusion This guide has walked you through the step-by-step process of setting up VNC on Ubuntu 22.04. We used TightVNC Server as the VNC server, TightVNC Viewer as the client, and Xfce as the desktop environment for user interaction with the server. We hope that using VNC technology helps streamline your server administration, making the process easier and more efficient. We're prepared more detailed instruction on how to create server on Ubuntu if you have some trouble deploying it.
21 August 2025 · 8 min to read
Servers

How to Correct Server Time

The method you choose for correcting the time on your server depends on how far off the server's clock is. If the difference is small, use the first method. If the clock is significantly behind or ahead, it's better not to adjust it in a single step — it's safer to change the time gradually. Configuration on Ubuntu/Debian Quick Fix To quickly change the time on the server, use the ntpdate utility. You need sudo privileges to install it: apt-get install ntpdate To update the time once: /usr/sbin/ntpdate 1.north-america.pool.ntp.org Here, the NTP pool is the address of a trusted server used to synchronize the time. For the USA, you can use NTP servers from this page. You can find pool zones for other regions at ntppool.org. You can also set up automatic time checks using cron: crontab -e 00 1 * * * /usr/sbin/ntpdate 1.north-america.pool.ntp.org This schedules synchronization once a day. Instead of a set interval, you can specify a condition. For example, to synchronize the time on every server reboot using cron reboot: crontab -e @reboot /usr/sbin/ntpdate 1.north-america.pool.ntp.org Gradual Correction To update the time gradually, install the ntp utility on Ubuntu or Debian. It works as follows: The utility checks data from synchronization servers defined in the configuration. It calculates the difference between the current system time and the reference time. NTP gradually adjusts the system clock. This gradual correction helps avoid issues in other services caused by sudden time jumps. Install NTP: apt-get install ntp For the utility to work correctly, configure it in the file /etc/ntp.conf. Add NTP servers like: server 0.north-america.pool.ntp.org server 1.north-america.pool.ntp.org iburst server 2.north-america.pool.ntp.org server 3.north-america.pool.ntp.org The iburst option improves accuracy by sending multiple packets at once instead of just one. You can also set a preferred data source using the prefer option: server 0.ubuntu.pool.ntp.org iburst prefer After each configuration change, restart the utility: /etc/init.d/ntp restart Configuration on CentOS The method choice rules are the same. If you need to correct a difference of a few seconds, the first method will do. For minutes or hours, the second method is better. Quick Fix To quickly adjust the time, use ntpdate. Install it with: yum install ntpdate For a one-time sync: /usr/sbin/ntpdate 1.north-america.pool.ntp.org Use Crontab to set automatic periodic synchronization. For daily sync: crontab -e 00 1 * * * /usr/sbin/ntpdate 1.north-america.pool.ntp.org To sync on boot instead of at regular intervals: crontab -e @reboot /usr/sbin/ntpdate 1.north-america.pool.ntp.org Gradual Correction To change the time on the server gradually, use ntp in CentOS. Install it: yum install ntp Enable the service on startup: chkconfig ntpd on In the file /etc/ntp.conf, specify accurate time sources, for example: server 0.north-america.pool.ntp.org server 1.north-america.pool.ntp.org iburst server 2.north-america.pool.ntp.org server 3.north-america.pool.ntp.org The iburst parameter works the same as in Ubuntu/Debian — it improves accuracy by sending a burst of packets. Restart the service after making changes: /etc/init.d/ntp restart Then restart the daemon: /etc/init.d/ntpd start Additional Options Time synchronization is usually done with the server closest to your server geographically. But in the configuration, you can specify the desired region directly in the subdomain. For example: asia.pool.ntp.org europe.pool.ntp.org Even if the NTP server is offline, it can still pass on system time. Just add this line: server 127.127.1.0 You can also restrict access for external clients. By default, these parameters are set: restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery The options notrap, nomodify, nopeer, and noquery prevent changes to the server's configuration. KOD (kiss of death) adds another layer of protection: if a client sends requests too frequently, it receives a warning packet and then is blocked. If you want to allow unrestricted access for the local host: restrict 127.127.1.0 To allow devices in a local network to sync with the server: restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap After any changes, restart the service: service restart ntp To check the service’s operation, use the command: ntpq -p It will display a table showing the time source address, server stratum, last synchronization time, and other useful data.
16 April 2025 · 4 min to read

Do you have questions,
comments, or concerns?

Our professionals are available to assist you at any moment,
whether you need help or are just unsure of where to start.
Email us
Hostman's Support