This led me to build NAGAHITAM.MY, a remote shell and server management platform developed primarily with Go.

The project is powered by a lightweight client called BD-NETCAT, which is designed to establish authenticated connections between managed server nodes and the management platform.

Why I Built It

There are already many tools available for remote server administration. However, I wanted to experiment with building a platform where remote shell access, node management, monitoring, and session management could work together as a single system.

The main goals were:

• Keep the client lightweight.

• Use Go for performance and portability.

• Provide centralized node management.

• Support authenticated connections.

• Provide basic system monitoring.

• Make remote administration straightforward for authorized infrastructure.

The project is also an opportunity to explore how a modern remote-management architecture can be designed from the ground up.

The Architecture

At a high level, NAGAHITAM.MY consists of three major components:

             Management Interface
                     │
                     ▼
              Platform Server
                     │
          Authenticated Connection
                     │
                     ▼
                 BD-NETCAT
                     │
                     ▼
              Managed Server

The management interface communicates with the platform server, while BD-NETCAT runs on an authorized server node.

The platform is responsible for authentication, node management, session coordination, and monitoring information.

BD-NETCAT

BD-NETCAT is the client component of the platform.

The objective is to keep the command-line experience simple while still providing authenticated communication with the management environment.

A typical command looks like:

bd-netcat -s "<NODE_TOKEN>" -i

The actual authentication token should always remain private and should never be committed to a public repository.

Built With Go

One of the main technical decisions behind the project was using Go.

Go is particularly interesting for this type of software because it provides:

• Fast compilation

• Low runtime overhead

• Straightforward concurrency

• Native networking capabilities

• Easy distribution as a single binary

• Support for multiple operating systems

For a lightweight server-management client, being able to distribute a relatively small executable is especially useful.

Node Management

A central part of NAGAHITAM.MY is the concept of managed nodes.

Administrators can use the platform to keep track of authorized servers and their connection status.

The management layer can provide information such as:

• Node availability

• Connection status

• CPU usage

• Memory usage

• Disk information

• Active sessions

• Authentication status

This gives administrators a centralized view instead of requiring them to manually check every server.

Remote Sessions

Another major component is interactive remote shell access.

The goal is to provide administrators with a convenient interface for accessing systems they are authorized to manage.

A typical workflow is:

Administrator
      │
      ▼
Management Interface
      │
      ▼
Select Authorized Node
      │
      ▼
Create Session
      │
      ▼
BD-NETCAT
      │
      ▼
Remote Shell

Keeping the session layer separate from the management interface also makes it easier to think about authentication, authorization, auditing, and connection lifecycle management.

Security Considerations

Remote administration software needs to treat security as a core feature rather than an afterthought.

NAGAHITAM.MY is designed around authenticated node connections and authorized administration.

Some important practices include:

• Keep authentication tokens private.

• Use encrypted connections in production.

• Restrict management access.

• Rotate compromised credentials.

• Avoid storing secrets in source code.

• Keep production configuration outside public repositories.

• Maintain appropriate access controls.

• Record relevant administrative activity where appropriate.

Sensitive information such as production credentials, private keys, database passwords, internal endpoints, and deployment configuration should never be published in the public repository.

Public vs Private Components

The public repository is intended to contain documentation and publicly distributable components.

Private infrastructure information remains separate.

This distinction is important when developing infrastructure-related software because publishing source code does not mean publishing every part of the production environment.

A public repository should never contain:

Production credentials
API secrets
Database passwords
Private keys
Authentication tokens
Internal infrastructure configuration
Private deployment files
Session secrets

Keeping these components separate makes the project easier to share publicly without exposing sensitive infrastructure.

What's Next?

There are several areas I would like to improve as development continues:

• Better system monitoring

• More detailed node metrics

• Improved session management

• Additional authentication controls

• Better auditing and logging

• Improved administration interface

• Additional operating system support

• Performance improvements

The roadmap will continue to evolve as the project develops and receives feedback.

Final Thoughts

NAGAHITAM.MY started as an experiment in building a modern remote server-management platform with Go.

The project combines several areas that I find interesting: networking, WebSocket communication, authentication, system monitoring, session management, and distributed client/server architecture.

The goal is not simply to create another remote-shell utility, but to build a complete management experience around authorized infrastructure.

If you are interested in Go, server management, networking, or infrastructure tooling, I would be interested in hearing your thoughts on the architecture and feature set.

Project: NAGAHITAM.MY
Client: BD-NETCAT

Use the software only on systems you own or have explicit authorization to administer.