DEV Community: Amin Haiqal

Understanding Bastion Hosts: The Quite Gatekeepers of Modern Infrastructure

Amin Haiqal — Sun, 03 May 2026 17:20:08 +0000

There is a moment every developer reaches, usually late at night, when something breaks and you realize you no longer understand your own setup.

At first, it feels manageable. One VPS, one IP address, one SSH command. You memorize it. You trust it. You build on top of it.

Then comes the second server. And the third. Suddenly you are juggling keys, IPs, environments, and access rules. You forget which key belongs to which machine. You paste commands from old terminal history hoping they still work. You log into the wrong server and restart the wrong service.

You tell yourself it is fine.

Then one day you notice something you should not ignore. Failed login attempts in your logs. Unknown IPs hitting port 22. Maybe nothing happens. Maybe something does and you do not notice until later.

And without realizing it, you have exposed multiple machines directly to the internet, each one listening on port 22, each one waiting.

This is where the idea of a bastion host enters. Not as a luxury, but as something you wish you had set up earlier.

The Bastion Host: A Single Door in a Wall of Servers

A bastion host is not complicated in concept, but it is powerful in consequence.

It is a single, hardened server that acts as the only entry point into your infrastructure.

Instead of connecting directly to every VPS you own, you connect to one machine, the bastion, and from there, you move inward.

In essence, you replace chaos with structure. Many doors become one.

Without a bastion host, your access pattern looks like this:

Your device → SSH → VPS A  
Your device → SSH → VPS B  
Your device → SSH → VPS C

Every server is exposed. Every server is a target.

With a bastion host, the pattern changes:

Your device → SSH → Bastion Host → SSH → Internal VPS

Now, only one machine is visible to the outside world. The rest exist behind it, quiet and unreachable unless you pass through the gate.

Why This Matters More Than It Seems

At first glance, this may feel like an unnecessary layer. After all, connecting directly works.

But infrastructure rarely fails loudly. It fails slowly, through small mistakes that stack up until something finally breaks.

A bastion host reduces those risks in ways that compound over time.

A Smaller Attack Surface

Instead of exposing every server, you expose only one. This drastically reduces the number of entry points an attacker can probe.

Centralized Control

Authentication, access policies, and SSH keys can be managed in one place. You no longer need to remember which key is on which machine or update them one by one.

Observability

A bastion host becomes a natural checkpoint. Every connection passes through it. Logging and auditing become practical instead of something you keep postponing.

Network Isolation

Your internal servers no longer need public IP addresses. They can live in private networks, invisible to the outside world.

The Mistakes That Lead Here

Most developers do not start with a bastion host. They arrive at it after something goes wrong.

Along the way, they make choices that feel harmless in isolation:

Opening port 22 on every VPS
Using password-based authentication because it is faster
Reusing SSH keys across multiple machines
Running everything as root because it is convenient
Skipping monitoring because nothing has broken yet

None of these decisions feel catastrophic on their own. But together, they create a system that is hard to reason about and easy to break.

A bastion host is not just a tool. It is a way to regain control.

Building a Bastion: The Practical Shape

At its simplest, setting up a bastion host involves:

Provisioning a dedicated VPS
Hardening SSH access (key-based authentication, disabling passwords)
Restricting inbound traffic via firewall rules
Allowing the bastion to connect to internal servers

From there, your workflow changes. You no longer connect directly to your target machines. You pass through the bastion on purpose.

It adds a step. But it also removes guesswork.

A Modern Shift: The Bastion in Your Browser

Traditionally, bastion hosts are accessed through terminal clients like PuTTY or Termius.

But the way we interact with systems is changing.

You are not always at your laptop. Sometimes you are on your phone, trying to fix something quickly. Maybe a service is down. Maybe a deployment failed. You open your terminal app and realize it is not set up, or the key is missing, or the connection fails.

You lose time when you do not have it.

This raises a practical question:

What if the bastion host itself exposed a web-based terminal?

Not a replacement for SSH, but a layer above it.

In this model, the flow evolves:

Phone browser  
   ↓  
Web application (hosted on bastion)  
   ↓ (WebSocket)  
Backend service  
   ↓ (SSH)  
Target VPS

Instead of opening a terminal app, you open a browser. The bastion becomes not just a gateway, but an interface you can reach from anywhere.

It is still SSH underneath. Still secure. Still structured. But now it is accessible when you actually need it.

The Trade-offs of This Approach

This modern approach introduces new capabilities, but also new responsibilities.

What You Gain

Access from any device, including mobile
A centralized interface for multiple servers
The ability to extend with features like session management or logging

What You Risk

Increased complexity in your system
A larger surface area at the application layer
The need for strong authentication and HTTPS enforcement

You are trading simplicity in infrastructure for flexibility in access.

Security: The Non-Negotiable Layer

A bastion host is only as strong as its configuration.

Whether traditional or web-based, certain principles remain constant:

Use SSH keys instead of passwords
Enforce HTTPS for any web interface
Implement authentication (sessions, tokens, or similar)
Apply rate limiting to prevent abuse
Isolate user sessions where possible

The bastion is your front line. If it is weak, everything behind it is exposed.

Where Bastion Hosts Quietly Power the World

This pattern is not niche. It is foundational.

Bastion hosts are used in:

Cloud environments to access private instances
Enterprise infrastructure for controlled internal access
DevOps workflows where environments must remain isolated

They are rarely visible in diagrams shown to end users, but they are almost always there.

Closing: From Convenience to Intentional Design

At the beginning, direct access feels faster. Simpler. Easier.

But as systems grow, that convenience turns into confusion. You forget what is exposed, what is protected, and what is safe.

A bastion host introduces a boundary. A place where access is deliberate instead of accidental.

It does not remove complexity. It gives you a way to manage it.

And over time, that difference matters more than anything else.

A Note on Practice

This exploration is not purely theoretical.

It is the foundation for an open-source project I am building, Axelyn Bastion, a lightweight, web-based bastion host designed for practical, mobile-friendly access to VPS environments.

If you're interested in following the project, exploring updates, or seeing how this idea evolves in practice, you can visit:

https://axelyn.com/

The goal is not to reinvent SSH, but to make it reachable when you actually need it.

Because the real problem is not connecting to your servers.

It is being able to do it when things are already going wrong.

I Thought This Was a Payment Problem. I Was Wrong.

Amin Haiqal — Thu, 30 Apr 2026 14:41:00 +0000

prev article

Amin Haiqal

Apr 29

Building a Strata Finance System (Because the Current Way Isn’t Working)

#webdev #programming #productivity #opensource

Comments

3 min read

What I Learned After Trying to Model Strata Finance Properly

When I first started thinking about this problem, I assumed it was simple.

Strata finance is just about tracking payments, right?

Who paid, who didn’t, and how much is outstanding.

But the moment I tried to model it properly, that assumption broke down.

It’s Not a Payment Problem

At first glance, it feels like the main job is to record money:

create charges
record payments
calculate balances

That part is straightforward.

The real complexity shows up when you try to answer questions like:

Why is this unit still overdue?
Did they already send payment?
Did someone follow up?
What happened last week?

That’s when you realize:

This is not just about money.

It’s about tracking what is happening over time.

Thinking in Terms of One Unit

To simplify things, I stopped thinking about the entire system.

I focused on just one unit.

Let’s say Unit A-12.

Every month, something predictable happens.

A new charge is created.

That charge represents what the unit owes for that month.

So far, nothing complicated.

Then Payments Come In

At some point, the resident makes a payment.

But here’s where things start to get messy in real life.

Payments don’t always match what is owed.

Someone might:

pay partially
pay for multiple months at once
send the wrong amount
send proof without clear reference

And most importantly:

The system cannot immediately assume the payment is valid.

So instead of marking it as “paid”, the system has to pause.

The payment exists, but it is waiting to be verified.

This small detail turns out to be very important.

Because this is where confusion usually starts.

One Payment, Multiple Charges

Another thing I didn’t expect at first:

A single payment is rarely clean.

If a unit owes for three months and pays one lump sum, that payment needs to be split across multiple charges.

So the system has to answer:

which charge is being paid first?
how much goes to each one?
what is still left unpaid?

This is something spreadsheets struggle with.

Because it’s not just a list anymore.

It’s a relationship.

The System Is Actually a Timeline

The biggest shift in thinking came from this realization:

A unit is not just “paid” or “unpaid”.

It goes through states.

At different points in time, the same unit can be:

newly billed
overdue
followed up
promised to pay
partially paid
disputed

And these states don’t replace each other.

They build on top of each other.

Which means the system needs to remember:

what happened
when it happened
who did it

Not just the final number.

Follow-Ups Matter More Than Numbers

Something else became very clear.

Most systems focus on:

charges
payments

But very few track what admins actually do.

In reality, collections depend heavily on:

calling residents
sending reminders
negotiating payments
escalating cases

If this is not recorded, the system is incomplete.

Because the most important question becomes unanswered:

What action has been taken so far?

Not Everyone Pays the Same Way

Another layer of complexity is human.

Some residents:

always pay on time
occasionally delay
never pay unless chased
request installment plans

Treating all units the same doesn’t work.

So the system needs a way to categorize behavior.

Not to label people—but to prioritize attention.

Because not all overdue cases are equal.

From Tracking to Clarity

At this point, I realized I wasn’t just building a way to record data.

I was trying to build something that answers a simple but powerful question:

Who needs attention right now?

That’s very different from:

Who hasn’t paid?

Because the first leads to action.

The second just creates a list.

What This Changed for Me

This shifted how I think about the system entirely.

Instead of focusing on features, I’m now focusing on:

how information flows
how states change over time
how decisions are made

The system is less about storing data, and more about making the current situation clear.

Where This Is Going

Now that the workflow is clearer, the next step is to translate this into something structured.

A system that can:

track charges and payments properly
handle partial and multi-month payments
record follow-ups consistently
classify units automatically
surface what needs attention

That’s what I’ll be building next.

If You’re Dealing With This

If you’ve ever had to manage collections, follow up on overdue payments, or piece together financial records manually, you’ve probably seen some version of this.

I’m actively building in this space, and also open to working with teams that want to improve their internal systems.

You can reach me here:
https://axelyn.com/

Building a Strata Finance System (Because the Current Way Isn’t Working)

Amin Haiqal — Wed, 29 Apr 2026 17:29:30 +0000

There’s a quiet kind of chaos in how many strata communities manage their finances.

On the surface, everything looks fine. There’s a spreadsheet somewhere. Numbers are filled in. Rows are coloured. Someone is “handling it.”

But the moment you start asking simple questions, things begin to fall apart.

Who still owes money?

How much?

Since when?

Did they already send their payment?

Was it verified?

Who followed up last?

No one has a clean answer. Not immediately. Not confidently.

Because the answers don’t live in one place.

They live across spreadsheets, WhatsApp conversations, emails, and memory. Sometimes in someone’s head. Sometimes nowhere at all.

Over time, the system becomes less of a system and more of a patchwork.

A spreadsheet is used to track balances. Another column is used to mark who has paid. Colours are introduced to signal urgency. Green means safe. Red means overdue. Yellow means “needs attention,” whatever that means this week.

Meanwhile, payment proofs arrive through WhatsApp. Screenshots, bank slips, forwarded messages. They get buried under new messages, lost in group chats, or forgotten entirely.

Follow-ups happen, but inconsistently. One admin calls. Another sends a message. Someone promises to pay. There is no record of it. A week later, the cycle repeats.

Residents dispute their balances. Admins double-check manually. Time is spent verifying things that should have been obvious.

Nothing is technically broken. But nothing is reliable either.

At some point, it becomes clear that the problem is not effort.

It’s structure.

So I started thinking about what a better system would look like; not in terms of features, but in terms of clarity. What if there was a single place that could answer, without hesitation:

Who owes what, since when, and what has been done about it?

That question became the starting point.

The system I’m building is not meant to replace people. It’s meant to replace the uncertainty around the work they are already doing.

Every charge—maintenance fees, sinking funds, penalties—should be recorded clearly, tied to a specific unit, with a known due date.

Every payment should be traceable. If a resident submits proof, it should not disappear into a chat thread. It should enter a flow. It should be verified or rejected. It should leave a trace.

Balances should not require manual calculation. They should exist as a result of what has already happened—charges issued, payments verified. Nothing more, nothing less.

Overdue units should not be guessed. They should be classified automatically, based on how long they’ve been unpaid, or whether they’ve ever paid at all.

And follow-ups; arguably the most human part of the process—should still be tracked. Not to control people, but to ensure continuity. So that when someone looks at a unit, they don’t just see numbers. They see history.

What was said. What was promised. What comes next.

Some residents won’t be able to pay everything at once. That’s reality.

So the system needs to handle that too. Installment plans shouldn’t live in scattered notes or informal agreements. They should be structured, visible, and measurable. Something both sides can understand.

When all of this comes together, the goal isn’t complexity.

It’s clarity.

A dashboard that doesn’t try to impress, but simply shows what matters. Total outstanding amounts. Overdue units. Payments waiting to be verified. The cases that need attention today.

Not more data. Just the right data, in the right place.

This is not just software for the sake of it.

It’s an attempt to turn a fragmented, manual workflow into something dependable. Something that reduces doubt instead of adding to it.

I’m building this in public because I don’t think this problem is unique.

If you’ve ever had to manage payments, follow up on overdue accounts, or piece together financial records from different places, you’ve probably seen some version of this.

So this is as much an exploration as it is a build.

What does a reliable workflow actually look like?

And how do we get there, step by step?

That’s what I’ll be figuring out next.

If you're dealing with this kind of workflow and trying to make it more reliable, I’d be interested to hear how you’re approaching it.

I’m currently building in this space, and also open to working with teams that want to improve their internal systems.

You can reach me here:
https://axelyn.com/

From Inventory Chaos to a Real-Time Command Center

Amin Haiqal — Mon, 27 Apr 2026 09:40:32 +0000

A system that doesn’t exist yet but probably should

At some point, every growing eCommerce system hits a strange wall.

Not traffic.
Not sales.
Not even infrastructure.

Just… inventory.

It usually starts small.

A product goes out of stock on one platform but still shows as available on another. An order slips through. Then another. Someone from operations jumps in, exports a CSV, fixes a number, uploads it back and by then those problems solved.

Until it happens again.

Now imagine that but across:

Shopify
multiple marketplaces
warehouse systems
internal spreadsheets

And none of them agree with each other.

The Moment Things Stop Making Sense

There’s a point where teams stop asking:

“Why is this wrong?”

…and start asking:

Which system is correct?

That’s when you know the problem isn’t operational anymore. It’s architectural. Because under the surface, every system believes it owns the truth.

A System With Too Many Writers

Inventory updates are happening everywhere:

orders reduce stock in Shopify
warehouses adjust quantities
internal tools override numbers manually

Each system writes data and none of them coordinate. From a distributed systems perspective, this is almost guaranteed to fail not because of bugs but because there is no single authority over state.

The Hidden Cost

At first, it looks like noise:

a few mismatches
some manual fixes
occasional refunds

But over time, the system starts leaking:

overselling becomes normal
stockouts happen while inventory still exists
operations slow down
decisions rely on outdated data

Eventually, growth itself becomes constrained. Not by demand. But by uncertainty.

The Shift in Thinking

At this point, it’s tempting to patch things:

add more sync jobs
increase polling frequency
introduce more scripts

But those don’t solve the problem. They just move it around. The real shift comes from re-framing the question and not

“How do we sync systems better?”

but

“What if no system is allowed to update inventory directly?”

That’s where this design begins.

A Different Approach: Treat Everything as an Event

Instead of letting systems mutate inventory freely:

Every change becomes an event.

an order is placed
stock is adjusted
a warehouse update happens

Nothing updates inventory directly anymore. Everything reports that something happened.

That single constraint changes everything.

Introducing a Controlled Flow

Once everything is an event, the system can enforce a pipeline:

Event → Queue → Processing → Central State → Sync Out

Instead of chaos, there is flow we can do and instead of conflict, there is order we can make.

Where the Real Control Happens?
At the center of this design is something intentionally restrictive:

A central inventory service.

It has one job which is maintain the only version of truth. No marketplace. No warehouse system. No internal tool. None of them are allowed to write inventory directly anymore. They can only send signals.

But why This Matters More Than It Seems?

This isn’t just about structure, it’s about control over state because once there is only one place where inventory can change:

conflicts can be detected
duplicates can be ignored
rules can be enforced consistently

Without that, consistency is mostly luck. Speaking reality, things will still go wrong even with this design. The system has to deal with:

duplicate events
delayed updates
simultaneous changes

So the pipeline need to include safeguards:

idempotency (so the same event doesn’t apply twice)
timestamps (to reject stale updates)
versioning (to prevent overwrites)

The Subtle but Important Flip

Before:
Every system tries to stay in sync with every other system.

After:
Every system stays in sync with one system.

That shift reduces complexity more than any optimization ever could then something interesting happens.Everything will became simpler once the central state is reliable

syncing outward is predictable
dashboards reflect reality
operations stop guessing

For the first time, someone can ask:

“What’s our stock right now?”

…and actually trust the answer.

This System Doesn’t Exist (Yet)

This is still a design.

A proposal. A system on paper.

But the problems it addresses are very real and I believe very common.

And the pattern shows up everywhere, whenever multiple systems are allowed to mutate the same data independently…

…consistency becomes an accident.

Final Thought

Most inventory problems don’t come from bad tools. They come from systems that were never designed to agree. Fixing that isn’t about adding more logic, it’s about deciding very clearly where truth is allowed to live.