DEV Community: arhuman

Your Servers Deserve Better: Meet Minexus, a Smart Admin Agent System in Go

arhuman — Tue, 01 Jul 2025 00:48:30 +0000

Meet Minexus — A Modular, Distributed Admin System in Go

I was tired of managing my servers with brittle scripts, ad hoc SSH sessions, and clunky monitoring tools. So I built Minexus, a modular platform to monitor and control servers via secure agents, with Go and gRPC under the hood.

If you’ve ever wanted:

To send a command to 50 machines and get results back fast
To build your own admin plugins with Go
To manage your servers like a well-oiled, distributed system

Then this might be up your alley.

Architecture at a Glance

Minexus is made of 3 main components:

Nexus — the central server, connected to a PostgreSQL DB

Minions — lightweight agents running on your hosts, communicating with the Nexus via gRPC + mTLS

Console — an admin UI and command interface, also talking to the Nexus

Minions register periodically. Commands go through the Nexus, and results are logged/stored. Want a new command? Just write a command.

It’s simple, extensible, and built for sysadmins/devops/devs who want control without vendor lock-in.

Use Cases:

Remote command execution (with return capture)
Service restarts across hosts
Health checks / monitoring plugins
Security scans (CVE lookup, etc.)

Anything you can plug into a Go module...

Want to send restart-service nginx to all your production servers and get clean results in seconds? Minexus can do that.

Current status

It's early days, but it’s usable and growing. Contributors welcome — the command system (soon a plugin system) makes it a playground for Go devs.

You're not a coder, it's not a problem: I’d love 🙏

Feedback on the architecture
Suggestions for useful commands/plugins
Help testing on non-Linux environments
Ideas to make this your go-to internal admin framework

Let’s Build This Together

I believe sysadmin/devops tooling should be:

Easy to use
Hackable
Fun to extend

If you agree, give Minexus a spin, drop a comment, or open an issue.

GitHub: https://github.com/arhuman/minexus

Cheers,

Why I like generics in golang

arhuman — Fri, 31 Jul 2020 22:20:33 +0000

(article originally written on my blog in French)

I was reading again the excellent article from Ian Taylon and Robert Grisemeer (The next step for generics) and I couldn't help thinking that I love the way we're heading. In fact, I love so much those new generics that I've decided to write an article to claim it.

With the latest drafts published, you should all have a precise idea about what the generics will look like in the next version of Go. So rather than writing another technical review about the changes, I'll rather state why I like those generics because it's the exact same reasons why I like the language.

I like generics because they're simple

As type parameters are special parameters, they're now handle as parameters (after the function name) but in an optional distinct list starting with the 'type' keyword and located before the usual parameters list.

func Process(type T)(s []T) {
    // do something with the slice of T
}

The call is similar to a standard call, specifying the type just before the parameters list.

Process(int)([]int{1, 2, 3})

In some cases (when all the types are used for the input parameter types and not in the body) the compiler is even able to deduce the type from the parameter types.

Constraints are now defined through interface type (no more contracts). For example, if we want the type T to implement String() we just have to add the Stringer interface constraint.

// Stringer is a type constraint that requires a String method.
// The String method should return a string representation of the value.
type Stringer interface {
    String() string
}

func Process(type T Stringer)(s []T) {
    // do something with the slice of T, and call String() on slice elements
}

And if we want to put a constraint on an operator, we can now use base types in an interface type by prefixing the list of base types with 'type'.

// Ordered is a type constraint that matches any ordered type.
// An ordered type is one that supports the <, <=, >, and >= operators.
type Ordered interface {
    type int, int8, int16, int32, int64,
        uint, uint8, uint16, uint32, uint64, uintptr,
        float32, float64,
        string
}

And to make your life even simple, a new type constraint 'comparable' is now available to handle '==' and '!=' operators

// Index returns the index of x in s, or -1 if not found.
func Process(type T comparable)(s []T)  {
    // Now you can compare elements of slice even if they're struct or array
}

Simple, isn't it?

I like generics because I like Gophers' community spirit

But beyond the feature added to the language, what I like with those new generics, is that the way they were added adhere to the community spirit.

you have to remember that generics were the 3rd point (with dependencies/package and errors handling) considered as the most important to improve according to 2016 Go users survey and 2017 one.

The fact that language evolution has been initiated based on the community feedback (rather than on choices made by a "benevolent dictator for life") is already great.

The pace at which the features were introduced is also an interesting metric:

Modules handling (introduced in version 1.11 in 2018)
Errors handling (introduced in version 1.13 in 2019)
Generic introduction (executed in version 1.15 due for end of 2020)

As we see, the release pace is quite fast but not rushed.

I like generics because I like Go's philosophy

Lastly, I like generics because they comply with the Go's philosophy.
(since the Go Brand Book published in 2018, I'd rather use the word values)

Simple: As seen above those generic is simple (bye bye contracts) with few language modifications.
Efficient: With every draft, performance has been a constraint and the last one manage to allow you to choose between faster compilation and slower execution and the contrary.
Thoughtful: Because instead of implementing generics based on another language, the community took its time to design one complying to the spirit of the language, to write drafts, to discuss them, to improve what can be improved and do it again to reach an implementation which complies to the language objectives and spirit without sacrificing to performance.

I like generics because it's practical

Go being a pragmatic language, you can already test this generic implementation on go2go playground

But as I tend to be optimistic and enthusiastic, maybe I got carried away, so let me ask you: And you, What do you think about this generics implementation?

How could you pretend to be Agile if you don't even know Scrum rituals?

arhuman — Tue, 03 Sep 2019 13:06:47 +0000

(Article originally posted on my blog)

That's more or less what I've been asked in a recent (failed) interview.
That was more subtle of course, but after being corrected on Scrum terminology,
failing to recognize the prevalence of the retrospective over the other rituals probably sealed the outcome of the interview.

I clearly didn't convinced my interviewer. My last Scrum experience was ten years ago. And would probably be considered as "Faux Agile" in actual terminology. So he was probably allowed to assert that I wouldn't be a good Scrum Master. But does that mean that I was not Agile?

As a pragmatic person, I neither stubbornly rejected his assertion nor did I slavishly waived my belief.
I did some work: I've read books and articles and I've asserted my processes and values.

Yes, values...
Because to me it allways boils down to values.

The Agile Manifesto

To understant why, let's get back in time, in 2001 to be precise.
Because it's in 2001 that the Agile movement was born.
Seventeen Software developers, published what is now known as the "Agile Manifesto".
This 68 words long text is considered to be the basis of the Agile movement.
But most important to me, they also proclaim 4 values that define what we now call Agility:

Individuals and Interactions over processes and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to Change over following a plan

At the same time they also presented 12 principles to enforce and develop those values but that's out of the scope of this article.

Regarding those values I could definitely consider myself as Agile.
I praise those values, and incidently I also follows several principles. And if you adhere to the Open Source culture you also probably do: The KISS principle, the “release early release often motto” are common illustrations of some of those principles.

eXtreme Programming

Going further, I discovered that prior to the Agile Manifesto, other (now considered) Agile methodologies existed, eXtreme Programming is one of those.

It also have values

Simplicity
Communication
Feedback
Respect
Courage

It happened that XP is also the first methodology I encountered as an Open Source software developer.
So without surprise, I also integrated those values long ago.

XP also defined several rules, similar to the Agile Manifesto principles.
Again, many rules will seems familiar to any Open Source software developer:

Integrate Often
All code must have unit tests.
All code must pass all unit tests before it can be released.
All production code is pair programmed.
Simplicity

And from this rules derived practices: Continuous integration, Test Driven Development, Pair programming...

Let's recap I check all the values, most of the rules, and several practices (especially as a CPANtester). So am I good, or is there something special about SCRUM that I miss?

Scrum

Let's see Scrum Values

Focus
Courage
Openness
Commitment
Respect

You probably noticed that it has 2 values in common with XP, the 3 remaining 'Focus', 'Openness' and 'Commitment' are related to the Scrum team.

Maybe we have an hint here.
As a XP developer, I feel I can claim an Agile ability. But in a Scrum Team ?

Sure some of the Scrum rituals are also XP practice (daily standing meeting) but as a single developer, it was not the practices I used.

Some people consider that Agility only make sense as a team member.
I can't just dismiss this belief but allow me to find it debatable: XP values does not require any team, and even the Agile Manifesto mention
individuals and interactions but without any precision this could well be related to a developer and its customer.

IMHO, Agility is all about improvement: team improvement, process improvement, technical improvement and self improvement.

Kanban

For completness (Scrum, Kanban, XP being the 3 most used methodologies) here are the Kanban values:

Understanding
Agreement
Respect
Leadership
Flow
Customer focus
Transparency
Balance
Collaboration

As a perceptive reader you might have spotted the 'Respect' value which is common to the others methodology.
To be honnest, I've never had the feeling that Kanban values were central to the methodology.
In what I've read, the core practices are often highlighted, and most of the time the values wheren’t even listed.
But may be I'm biased, I'm not sure people know XP values more than TDD or pair programming.

Conclusion

Back to the original question, I'm confident saying that I'm Agile even if I'm not an experienced Scrum Master or even practicionner.
First, because Scrum isn't the only Agile methodology out there and besides XP there are also Kanban, RAD, Lean SD, Wild Agile and many others.
Then and above all, because I follow/praise/put in practice values which are at the heart of many Agile methodologies (including Scrum).

Going further I think that the simple fact of restricting Agility to a process knowledge is an anti-Agile pattern to me (Remember "Individuals and Interactions over processes and tools"?)

That doesnt mean Rituals/practices are useless, they are a good way to check that you actually enforce the values you pretend to follow.
But they are only meaningfull if you remember and adhere to the associated values:
Attending a daily standing melee, with people you don't respect, staying silent on the encountered issues to hide that you screwed your task because you're just lazy is by no mean 'Agile'.

On my side, I'm aware that rituals/practices are the best way to enforce/check those values and I will go on improving my knowledge of all rituals/practices and of the associated principle. After all constant improvement is one of the 12 principles of the Agile Manifesto...

Credits

I'd like to thanks my peers from Happy Dev for their reviews/advices/insights.
And I'd like to express my gratitude to the interviewer mentioned in the article: he forced me to re-think my Agile stance, convinced me to improve my Scrum knowledge and reminded me that self-improvement is a daily duty.