DEV Community: leone

[Boost]

leone — Tue, 14 Oct 2025 15:52:59 +0000

Deploy a complete media center on Nanocl

leone ・ Oct 14

#beginners #devops #tutorial #nanocl

[Boost]

leone — Wed, 17 Sep 2025 06:52:43 +0000

Deploy Vaultwarden on Nanocl

leone ・ Sep 17

[Boost]

leone — Tue, 09 Sep 2025 18:45:33 +0000

How to easily create a CLI in Rust using clap and clap_mangen

leone ・ Sep 9

#programming #rust #tutorial #beginners

[Boost]

leone — Mon, 08 Sep 2025 22:25:37 +0000

Your Own Private Internet with Nanocl and WireGuard

leone ・ Sep 8

[Boost]

leone — Fri, 05 Sep 2025 17:24:44 +0000

Basic http proxy in rust with ntex

leone ・ Sep 5

#webdev #programming #rust #tutorial

[Boost]

leone — Fri, 05 Sep 2025 17:19:36 +0000

Automating deployment with GitHub Actions and Nanocl

leone ・ Sep 5

#devops #beginners #tutorial #webdev

[Boost]

leone — Thu, 04 Sep 2025 19:39:41 +0000

Solving the Localhost Development Headache with Nanocl

leone ・ Sep 4

#webdev #beginners #tutorial #productivity

[Boost]

leone — Wed, 03 Sep 2025 09:46:53 +0000

leone

Sep 3 '25

REST API in RUST with ntex

#webdev #programming #rust #tutorial

Comments

9 min read

Basic http proxy in rust with ntex

leone — Wed, 18 Dec 2024 12:38:09 +0000

What is ntex ?

Ntex is a powerful, pragmatic, and extremely fast framework for composable networking services for Rust.
It's one of the fastest web frameworks available in Rust, and provides powerful abstractions for web server development.

Why ntex ?

This are my top reasons for using ntex:

Performance: Ntex is one of the fastest web frameworks available in Rust.
Ergonomic: Ntex provides powerful abstractions for web server development.
Composable: Ntex is designed to be composable, allowing you to build complex web servers from simple components.
Ecosystem: Ntex has a rich ecosystem of middleware, extensions and libraries.
Built-in http client: Ntex provides a built-in http client for making requests to other servers.
Runtime: Ntex allow you to choose between different runtimes, including tokio and async-std.

Setting up the project

Let's start by creating a new project with cargo:

cargo new ntex-http-proxy
cd ntex-http-proxy

Add ntex as dependency:

cargo add ntex --features tokio

Starting with a basic http handler

Let's start by creating a basic http handler that will return Hello, World! in plain text format:

use ntex::{http, web};

async fn forward() -> Result<web::HttpResponse, web::Error> {
  Ok(
    web::HttpResponse::Ok()
      .content_type("text/plain")
      .body("Hello, world!"),
  )
}

#[ntex::main]
async fn main() -> std::io::Result<()> {
  web::server(move || {
    web::App::new()
      .state(http::Client::new())
      .wrap(web::middleware::Logger::default())
      .default_service(web::route().to(forward))
  })
  .bind(("0.0.0.0", 9090))?
  .run()
  .await
}

Let's break down the code:

forward is an async function that returns a web::HttpResponse or a web::Error.
main is the entry point of our application. It's an async function that returns a std::io::Result<()>.
We create a new ntex web server with web::server and pass a closure that returns a web::App.
We create a new http::Client and add it to the app state.
We add a logger middleware to the app.
We define a default service that will forward all requests to the forward handler.
We bind the server to 0.0.0.0:9090 and run it.

Let's test the server by running it:

cargo run
curl http://localhost:9090

You should see Hello, world! in the response.

Adding a proxy handler

We start by adding the url and futures_util crates to our dependencies to be able to parse urls and convert responses to streams:

cargo add url futures-util

Then we change the the code to forward requests to another server:

use futures_util::TryStreamExt;
use ntex::{http, web};

async fn forward(
  req: web::HttpRequest,
  body: ntex::util::Bytes,
  client: web::types::State<http::Client>,
  forward_url: web::types::State<url::Url>,
) -> Result<web::HttpResponse, web::Error> {
  let mut new_url = forward_url.get_ref().clone();
  new_url.set_path(req.uri().path());
  new_url.set_query(req.uri().query());
  let forwarded_req = client.request_from(new_url.as_str(), req.head());
  let res = forwarded_req
    .send_body(body)
    .await
    .map_err(web::Error::from)?;
  let mut client_resp = web::HttpResponse::build(res.status());
  let stream = res.into_stream();
  Ok(client_resp.streaming(stream))
}

#[ntex::main]
async fn main() -> std::io::Result<()> {
  let forward_url = "https://www.rust-lang.org".to_owned();
  let forward_url = url::Url::parse(&forward_url)
    .map_err(|err| std::io::Error::new(std::io::ErrorKind::InvalidData, err))?;
  web::server(move || {
    web::App::new()
      .state(http::Client::new())
      .state(forward_url.clone())
      .wrap(web::middleware::Logger::default())
      .default_service(web::route().to(forward))
  })
  .bind(("0.0.0.0", 9090))?
  .run()
  .await
}

Let's break down the code:

We add the url and futures_util crates to our dependencies.
We change the forward function to take the request, body, client and forward_url as arguments.
We create a new url by cloning the forward_url and setting the path and query from the request.
We create a new request using the client and the new url.
We send the body of the request and await the response.
We build a new response with the status code of the response.
We convert the response into a stream and return it.

Let's test the server by running it:

cargo run
curl http://localhost:9090

You should see the rust-lang.org homepage in the response.

Conclusion

In this tutorial, we created a basic http proxy server using ntex. We started by creating a simple http handler that returns Hello, World! in plain text format. Then we added a proxy handler that forwards requests to another server. We used the url and futures_util crates to parse urls and convert responses to streams. We tested the server by running it and making a request to it. We saw that the server successfully forwarded the request to the target server and returned the response.
We have little to no code to write a basic http proxy server (less than 50 lines of code) and we can easily extend it with more features like caching, rate limiting, authentication, etc.

I hope you enjoyed this tutorial and found it useful. If you have any questions or feedback, feel free to leave a comment below.

[Boost]

leone — Thu, 28 Nov 2024 05:19:48 +0000

Automating deployment with GitHub Actions and Nanocl

leone ・ Nov 24 '24

#webdev #tutorial #beginners #devops

Automating deployment with GitHub Actions and Nanocl

leone — Sun, 24 Nov 2024 17:35:58 +0000

Learn how to automate your deployment with GitHub Actions and Nanocl. This guide walks you through setting up seamless deployments, making it easier to deploy your applications with minimal effort. Whether you're new to CI/CD or an experienced developer, this post will show you how to streamline your workflow using powerful open-source tools.

Introduction

Continuous Integration and Continuous Deployment (CI/CD) are essential practices in modern software development. They help automate the process of building, testing, and deploying applications, making it easier to deliver high-quality software quickly and efficiently. GitHub Actions is a powerful tool that allows you to automate your CI/CD pipeline directly from your GitHub repository. Nanocl is a containers and virtual machine orchestrator that simplifies the deployment process by providing a unified interface for managing your infrastructure.

In this blog i will showcase how i did setup our CI/CD pipeline with Github Actions and Nanocl for the deployment of next-hat and and ntex.rs documentation that use docusaurus.

Prerequisites

Before we get started you need a few things:

A GitHub account (you can sign up for free at github.com)
A project to deploy (it can be a static website, a web application, or anything that can run in a container)
A dedicated server or a VPS (i use ovh for servers)
A domain name that point to your server (i use ovh for domain names)
Docker installed on your local machine and server (you can find the installation instructions here)
Nanocl installed on your server (you can find the installation instructions here)

Creating the container image

We will take a look on how to create the container image for the deployment of the documentation of next-hat and ntex.rs that use docusaurus. If you already know how to setup a docker container image you can skip this section.

Creating a Nginx Configuration File

We use nginx as a web server to serve the static files generated by docusaurus. The server.nginx file contains the configuration for the nginx server. You can replace it with your own configuration file to match your use case.

server {
  listen       80;
  listen  [::]:80;
  rewrite ^/(.*)/$ /$1 permanent;

  gzip on;
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 8;
  gunzip on;
  gzip_types application/javascript image/* text/css;
  gzip_disable "MSIE [1-6]\.";

  root /home/node/app;
  error_page 404 /404.html;
  try_files $uri.html $uri/index.html =404;

  ## All static files will be cached.
  location ~* ^.+\.(?:css|webp|cur|js|jpe?g|gif|htc|ico|png|html|xml|otf|ttf|eot|woff|woff2|svg)$ {
    access_log off;
    expires 1y;
    add_header Cache-Control max-age=31536000;

    ## No need to bleed constant updates. Send the all shebang in one
    ## fell swoop.
    tcp_nodelay off;

    ## Set the OS file cache.
    open_file_cache max=3000 inactive=120s;
    open_file_cache_valid 45s;
    open_file_cache_min_uses 2;
    open_file_cache_errors off;
  }
}

Let's break down the server.nginx configuration file:

server { ... }: This block defines the configuration for the Nginx server.
listen 80;: This line specifies that the server should listen on port 80.
rewrite ^/(.*)/$ /$1 permanent;: This line redirects requests with a trailing slash to the same URL without the slash.
gzip on;: This line enables gzip compression for responses.
root /home/node/app;: This line specifies the root directory for serving static files.
error_page 404 /404.html;: This line specifies the error page to use for 404 errors.
try_files $uri.html $uri/index.html =404;: This line specifies the files to try when a request is made.
location ~* ^.+\.(?:css|webp|cur|js|jpe?g|gif|htc|ico|png|html|xml|otf|ttf|eot|woff|woff2|svg)$ { ... }: This block specifies the configuration for serving static files with caching enabled.

This configuration file optimizes the Nginx server for serving static files and improves performance by enabling gzip compression and caching.

Creating a Dockerfile

A Dockerfile is a text document that contains all the commands needed to build a Docker image. It specifies the base image to use, the commands to run, and the files to copy into the image. In this guide, we will create a Dockerfile for a docusaurus website. You can replace the commands with the ones needed for your project.

Create a new file in your project directory called Dockerfile. This file will contain the configuration for your Docker image. Here is an example Dockerfile for a docusaurus website:

FROM node:22.11.0-alpine AS builder

RUN apk add git

USER node

# Create app directory (with user `node`)
RUN mkdir -p /home/node/app
# Set is as cwd
WORKDIR /home/node/app

# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm@5+)
COPY --chown=node package*.json ./

# Install dependencies
RUN npm install

# Bundle app source code
COPY --chown=node . .
COPY --chown=node ./.git ./.git

RUN npm run build

FROM nginx:1.27.0-alpine3.19-slim

WORKDIR /etc/nginx/conf.d

COPY --from=builder /home/node/app/build /home/node/app

COPY ./server.nginx ./default.conf

Let's break down the Dockerfile:

FROM node:22.11.0-alpine AS builder: This line specifies the base image to use for the build stage. We use the node:22.11.0-alpine image, which is a lightweight version of Node.js that includes npm.
RUN apk add git: This line installs the git package, which is needed to clone the repository.
USER node: This line switches to the node user, which is a non-root user created by the Node.js image.
RUN mkdir -p /home/node/app: This line creates a directory for the application code.
WORKDIR /home/node/app: This line sets the working directory to the application directory.
COPY --chown=node package*.json .: This line copies the package.json and package-lock.json files into the image.
RUN npm install: This line installs the dependencies specified in the package.json file.
COPY --chown=node . .: This line copies the application code into the image.
COPY --chown=node ./.git ./.git: This line copies the .git directory into the image.
RUN npm run build: This line builds the application using the npm run build command.
FROM nginx:1.27.0-alpine3.19-slim: This line specifies the base image to use for the final image. We use the nginx:1.27.0-alpine3.19-slim image, which is a lightweight version of Nginx.
WORKDIR /etc/nginx/conf.d: This line sets the working directory to the Nginx configuration directory.
COPY --from=builder /home/node/app/build /home/node/app: This line copies the static files generated by the build stage into the Nginx configuration directory.
COPY ./server.nginx ./default.conf: This line copies the server.nginx file into the Nginx configuration directory.

This Dockerfile creates a multi-stage build that first builds the application using Node.js and then copies the static files into an Nginx image. This approach reduces the size of the final image and improves performance by separating the build dependencies from the runtime dependencies.

Building and Running the Docker Image Locally

Before deploying your application to your server, you should test the Docker image locally to ensure that it works as expected. You can build and run the Docker image on your local machine using the following commands:

docker build -t my-image .
docker run -p 8080:80 my-image

The docker build command builds the Docker image using the Dockerfile in the current directory and tags it with the name my-image. The docker run command runs the Docker image on port 8080, mapping it to port 80 inside the container. You can access the application by opening a web browser and navigating to http://localhost:8080.

If everything works as expected, you should see a production version of your docusaurus website running in the browser. You can now proceed to deploy your application to your server using GitHub Actions and Nanocl.

Setting up Nanocl

Nanocl is a powerful tool that simplifies the deployment process by providing a unified interface for managing your infrastructure. You can use Nanocl to deploy your applications to your server with minimal effort. In this guide, we will show you how to set up Nanocl on your server and deploy your application using a simple configuration file.

First, you need to install Nanocl on your server. You can find the installation instructions here. Once you have installed Nanocl, you can create a configuration file for your application. This file will contain the settings for your application, such as the image name, port number, and environment variables.

By default once installed Nanocl is only accessible via /run/nanocl/nanocl.sock. You can use a proxy rule to expose it to the public internet, however, exposing it to the public without a self signed SSL/TLS certificate is not recommended.
It could allow an attacker to take control of your server.
Hopefully, we have a pre-configured rule that you can apply to expose the Nanocl Daemon.

On your dedicated server or VPS, run the following command to apply the rule:

nanocl state apply -fs https://nr.next-hat.com/v0.16/sys/enable-remote-nanocld.yml

It will expose the Nanocl Daemon to the public internet with a self signed SSL/TLS certificate on the port 9943.

Setting up Github Secrets

GitHub Secrets allow you to securely store and use sensitive information in your GitHub repository. You can use GitHub Secrets to store your server credentials, API keys, and other sensitive information needed to deploy your application. In this guide, we will use GitHub Secrets to store the credentials needed to deploy your application to your server using Nanocl.

To get started, go to your GitHub repository and click on the Settings tab. Then, click on the Secrets and variables link in the left sidebar. Click on the Actions link.

You should see a page like this:

Click on the New repository secret button to create a new secret. You can create a secret for each of the following values:

NANOCL_HOST: The hostname or IP address of your server with the 9943 port. Example: https://example.com:9943
NANOCL_CERT: The content of the self signed SSL/TLS certificate used to secure the connection to the Nanocl Daemon.
NANOCL_CERT_KEY: The content of the private key used to secure the connection to the Nanocl Daemon.

You can find the content of the certificate and private key by running the following commands on your server:

nanocl secret inspect cert.client.nanocl.io

This command will output the content of the certificate and private key. You can copy and paste the content into the GitHub Secrets page.

Creating a Statefile Configuration

A Statefile is a configuration file that contains the settings for your application. It specifies the image name, port number, and environment variables needed to deploy your application. You can create a Statefile for your application and use it to deploy your application to your server using Nanocl.
This is the Statefile i use for the deployment of the next-hat documentation:

ApiVersion: v0.16

Args:
- Name: version
  Kind: String

Cargoes:
- Name: nh-doc
  Container:
    Image: ghcr.io/next-hat/documentation:${{ Args.version }}

Resources:
- Name: http.docs.next-hat.com
  Kind: ncproxy.io/rule
  Data:
    Rules:
    - Domain: docs.next-hat.com
      Network: Public
      # Secret created for the certbot job below
      # You can remove this line if you don't want https
      Ssl: cert.docs.next-hat.com
      Locations:
      - Path: /
        Target:
          Key: nh-doc.global.c
          Port: 80
    - Domain: docs.next-hat.com
      Network: Public
      Locations:
      - Path: /
        Target:
          Url: https://docs.next-hat.com
          Redirect: Temporary

This Statefile must be placed in the root of your project directory.

Setting up GitHub Actions

GitHub Actions allow you to automate your workflow directly from your GitHub repository. You can create custom workflows that run on specific events, such as pushing code to your repository or creating a pull request. In this guide, we will create a workflow that builds and deploys your application to your server using Nanocl.
You can find the full source code here

Building and Publishing the Docker Image

To get started, create a new file in your repository called .github/workflows/build-and-publish.yml. This file will contain the configuration for your GitHub Actions workflow. And will be used to build your docker image and publish it to github container registry. Only when we are merging to master branch.

name: Build and publish docker image

on:
  push:
    branches:
      - master

jobs:
  deploy:
    name: Build and publish docker image
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract version from package.json
        id: extract_version
        run: |
          version=$(jq -r '.version' package.json)
          echo "PACKAGE_VERSION=$version" >> $GITHUB_ENV

      - name: Check if version already exists
        id: check_version
        run: |
          VERSION=${{ env.PACKAGE_VERSION }}
          IMAGE_NAME=ghcr.io/${{ github.repository_owner }}/my-image
          if docker manifest inspect $IMAGE_NAME:$VERSION > /dev/null 2>&1; then
            echo "Version $VERSION already exists."
            exit 1
          fi
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: |
            ghcr.io/${{ github.repository_owner }}/documentation:latest
            ghcr.io/${{ github.repository_owner }}/documentation:${{ env.PACKAGE_VERSION }}

This workflow will run every time you merge code in the master branch of your repository. It will build a docker image from your code, tag it with the latest version from your package.json file, and push it to the GitHub Container Registry. You can replace documentation with your image name.

Deploying the Application with Nanocl

Next, create a new file in your repository called .github/workflows/deploy.yml. This file will contain the configuration for your GitHub Actions workflow. And will be used to deploy your application to your server using Nanocl.

name: Deploy

on:
  workflow_run:
    workflows: ["Build and publish Docker image"]
    types:
      - completed

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v3

    - name: Install nanocl cli
      run: |
        wget https://github.com/next-hat/nanocl/releases/download/nanocl-0.16.2/nanocl_0.16.2_amd64.deb
        sudo dpkg -i nanocl_0.16.2_amd64.deb
        rm nanocl_0.16.2_amd64.deb

    - name: Deploy to production
      run: |
        VERSION=$(jq -r '.version' package.json)
        nanocl version
        echo $VERSION
        nanocl state apply -ys Statefile.yml -- --version $VERSION
      env:
        HOST: ${{ secrets.NANOCL_HOST }}
        CERT: ${{ secrets.NANOCL_CERT }}
        CERT_KEY: ${{ secrets.NANOCL_CERT_KEY }}

This workflow will run every time the Build and publish Docker image workflow is completed. It will deploy your application to your server using Nanocl. You can replace Statefile.yml with the path to your Statefile configuration file if you have a different name of path.

Now you have set up your CI/CD pipeline with GitHub Actions and Nanocl. Every time you push code to your repository, GitHub Actions will build and publish your Docker image to the GitHub Container Registry. Once the image is published, it will trigger the deployment workflow, which will deploy your application to your server using Nanocl.

Enable public SSL/TLS with Let's Encrypt

Additionally you can enable public SSL/TLS with Let's Encrypt. You can use the following command to enable public SSL/TLS with Let's Encrypt:

nanocl state apply -fs https://nr.next-hat.com/v0.16/sys/certbot.yml -- --email contact@next-hat.com --domain docs.next-hat.com

Conclusion

By following the steps outlined in this guide, you can automate the deployment of your applications to your server with minimal effort and zero downtime. This will help you deliver high-quality software quickly and efficiently, making it easier to manage your infrastructure and deploy your applications with confidence.

Now that you know how to automate your deployment with GitHub Actions and Nanocl, why not give it a try with your own project? Let us know how it goes or if you have any questions!

You can join my discord server if you have any questions or need help with setting up your CI/CD pipeline with GitHub Actions and Nanocl. I'm here to help you succeed in your software development journey.

Solving the Localhost Development Headache with Nanocl

leone — Thu, 09 May 2024 15:38:42 +0000

Developers often face significant challenges when working on projects locally, especially when it comes to managing multiple services, dealing with CORS and cookies, and ensuring that the development environment mirrors production. However, there's a promising solution on the horizon: Nanocl.

Introducing Nanocl

Nanocl is a powerful tool designed to streamline project deployment and alleviate the pains associated with localhost development. By seamlessly integrating with your development workflow, Nanocl simplifies the process of running multiple services locally and eliminates common headaches like CORS issues, port conflicts and cookies.

The Problem at Hand

Consider a scenario where you're working on a project consisting of various components—an API, a dashboard, and a login page. Traditionally, you would need to run each of these components on different ports, leading to cumbersome setups and potential conflicts. Additionally, issues like CORS and cookies become apparent, especially when these services aren't bound to a specific domain. Managing these challenges manually can be time-consuming and error-prone, detracting from your productivity and focus on actual development tasks.

How Nanocl Comes to the Rescue

Nanocl provides a comprehensive solution to the localhost development headache. By leveraging its powerful features, developers can streamline their workflow and focus on building great software without getting bogged down by infrastructure complexities.

Seamless Integration

Nanocl seamlessly integrates with your existing development environment, allowing you to deploy your project with a single command. Gone are the days of juggling multiple terminals and wrestling with configuration files—Nanocl handles it all for you.

Domain Resolution

One of Nanocl's standout features is its ability to create domains for your local machine, bringing your development environment closer to production. With Nanocl, you can access your services using intuitive domain names like api.dev.internal, console.dev.internal, and auth.dev.internal, making testing and debugging a breeze.

Realistic Testing Environment

By replicating the production setup locally, Nanocl enables developers to test their projects in a more realistic environment. This ensures smoother transitions from development to production and reduces the likelihood of encountering unforeseen issues down the line.

Getting Started with Nanocl

Ready to kiss localhost headaches goodbye? Here's how to get started with Nanocl:

Installation: Refer to the Nanocl documentation for detailed instructions on installing Nanocl on your machine.
Clone the Example Repository: Once Nanocl is installed, clone the example repository provided to see Nanocl in action.
```
git clone https://github.com/leon3s/solving-localhost-dev
```
Run the Project: Navigate to the cloned repository and run the project using Nanocl.
```
cd solving-localhost-dev
nanocl state apply -fs Statefile.yml
```
Update /etc/resolve.conf: Retrieve the IP address of the DNS server by running the following command:
```
nanocl namespace ls
```
The output will display the IP address of the DNS server, which you'll need to add to your /etc/resolve.conf file.
```
NAME      CARGOES    INSTANCES    GATEWAY     CREATED AT
system    7          7            10.1.0.1    2024-05-09 15:52:27
global    4          4            10.2.0.1    2024-05-09 15:52:27
```
Update your /etc/resolve.conf file with the IP address of the gateway:
```
nameserver <global-namespace-gateway-ip>
```
Access Your Domains: Once the setup is complete, you can access your services using the designated domains (api.dev.internal, console.dev.internal, auth.dev.internal). Enjoy a headache-free development experience!

How it works

Nanocl will parse the Statefile.yml to know the current state of the services. It will then create the necessary namespaces, cargoes, and instances to run the services. The services will be available at the domains specified in the Statefile.yml.

With a combinaison of a DNS server and a reverse proxy, Nanocl will resolve the domains to the correct services.

Key Takeaways

Simplified Development Workflow: Nanocl streamlines the process of running multiple services locally, enabling developers to focus on building great software.
Domain Resolution: Nanocl help you to setup intuitive domains for your services, making it easier to test and debug your projects.
Realistic Testing Environment: By mirroring the production setup locally, Nanocl helps developers identify and resolve issues early on, leading to smoother deployments.
Seamless Integration: Nanocl seamlessly integrates with your existing development environment, eliminating the need for manual configurations and complex setups.

Conclusion

With Nanocl, localhost development doesn't have to be a headache anymore. By providing a seamless solution to common challenges, Nanocl empowers developers to focus on what they do best—building innovative software. Say goodbye to CORS woes, port conflicts and cookies problems, and hello to a smoother, more efficient development workflow. Give Nanocl a try today and unlock a world of possibilities for your projects. Happy coding!