DEV Community: taeyeong

Alpacon: Identity, Automation, and Auditing (Part 2)

taeyeong — Thu, 02 Oct 2025 00:38:03 +0000

In Part 1, we covered how Alpacon reimagines network access through Websh.
This is Part 2: Identity & Access Management, Integrations & Interoperability, and Auditing.

Identity & Access Management

When a new developer joins, have you ever issued an SSH ID and password, then sent the server IP and port via Slack? Or asked them to send you their SSH public key to manually register on the server?
Did that feel secure and scalable?

Identity is a prime target for attacks. Passwords are no longer valid security credentials. Identities provisioned on servers easily become outdated without proper tracking—creating vulnerabilities for hackers or giving disgruntled former employees access to critical assets.

Centralized Management
Alpacon centrally manages all identities used to access servers.

New employee → Invite to Alpacon
Employee leaves → Remove from Alpacon

When users first connect, their ID and permissions are automatically provisioned. As changes occur, Alpacon tracks them continuously. System accounts are created as passwordless. Logging in through other means isn't possible.

Enforced MFA
Workspace admins can require enhanced MFA when users connect in privileged mode (typically root access). Supported methods:

Biometric, Hardware security keys, OTP, Email, SMS

Enterprise Integration

Google Workspace integration
SAML support coming soon
Security-designed and white-hat verified
Redundant architecture prevents single points of failure

Integrations & Interoperability

Have you needed to give SSH access to CI/CD pipelines? Did you open your firewall to allow GitHub Actions or GitLab CI/CD with dynamic IPs? Were you worried about deployment SSH keys being misused?

Alpacon CLI and REST API
Execute workloads and transfer files with a single command. The CLI uses SSH-like syntax for familiarity.

alpacon login https://alpacon.io/my-workspace -t "alpat-..."
alpacon cp docker-compose.yml prod-docker:/opt/my-app/
alpacon cp .env prod-docker:/opt/my-app/
alpacon websh prod-docker docker compose -p my-app --env-file .env up -d

Fine-Grained Control
Tokens protected by fine-grained rules can only execute permitted commands. Block unauthorized parties from abusing CI to execute arbitrary commands.

curl -X POST https://my-workspace.us1.alpacon.io/api/events/commands/ \
     -H "Content-Type: application/json" \
     -H "Authorization: Token alpat-..." \
     -d '{"server": "7a50ea6c-2138-4d3f-9633-e50694c847c4", "line": "docker ps", "username": "docker"}'

Integrate safely with CI/CD under strong control.

Auditing

Do you track who executed what commands on your servers and when? Many companies don't know who caused an issue even when incidents occur. Access to critical assets should be monitored, but few actually do it.

Full Visibility
Alpacon logs all user connections as an access gateway:

Real-time monitoring of terminal access
Block suspicious activity immediately
Post-incident command audit
Complete command history with timestamps and attribution

You know who accessed which server, when they connected, what commands were executed, where the access came from, and how they authenticated.
No more blind spots. No more guessing. Just complete accountability.

Concluding Thoughts

Why have we assumed that stronger security must mean harder access?
Alpacon proves you don't have to choose. Security and accessibility aren't opposites—they're two sides of the same modern infrastructure.

What's Next?

We built Alpacon because we were tired of the same old problems: dropped SSH sessions, manual key management, and zero visibility into who's doing what.

If you've felt the same frustration, we'd love to have you try it.

Get Started:

🚀 Join the Beta and see how Alpacon works in your environment
💬 Join Discord to share your experience and help shape what we build next

We're building this in the open. Your feedback matters.

Alpacon: Network Access and Resource Management (Part 1)

taeyeong — Tue, 30 Sep 2025 00:28:07 +0000

We've talked about the problems with SSH and VPN. We've explained why the old model no longer works.
Now it's time to show you what we built instead.
This is Part 1 of how Alpacon redefines server access: Network Access with Websh, Accessibility Without VPNs, and Resource Management.

Network Access with Websh

Alpacon sits between clients and servers as an access gateway.
Instead of relying on SSH, we built our own protocol: Websh—designed from the ground up for scalability, security, and modern infrastructure.
How Websh Works

No privileged ports required: No more opening port 22 or managing firewall rules
Reverse connection model: Servers initiate connections to Alpacon; no inbound ports exposed
Always runs over TLS: Cryptographic security by default, no configuration needed
SSH risks reduced to zero: Attackers can't scan for port 22 because it's not there

Traditional SSH exposes servers to the internet. Websh hides them behind Alpacon's gateway.
One less attack surface. One less thing to worry about.

Accessibility Without VPNs

Have you ever lost an SSH session mid-task because of a flaky VPN or unstable network?
We have. Too many times.
Persistent Sessions
Alpacon's Websh sessions persist until the user explicitly ends them.

Close your laptop
Change networks
Reconnect WiFi
Switch from office to home

Your session is still there.
No reconnecting. No lost work. No frustration.
Mobile Access
Even better: Alpacon gives you instant shell access from a mobile browser.

No VPN required
No client installation
Just open the browser and connect

Emergency fix at 2AM while you're away from your laptop? No problem.

Resource Management

Managing servers shouldn't require spreadsheets, Slack threads, and tribal knowledge.
Alpacon makes it simple.
One-Line Server Registration
Admins can register all servers into a workspace in minutes:

Paste a one-line script into the terminal
Agent installs automatically
Server is live in Alpacon

That's it.
Real-Time Visibility

All servers monitored in real time
Grouped by team, role, or project
Access granted with role-based controls
No more "who owns this server?" confusion

Centralized Control

Onboard a new teammate → grant access to their servers instantly
Someone leaves → revoke everywhere with one click
Need to rotate credentials? Done across all servers at once

Everything in one place. Everything under control.

What's Next?
This is just Part 1.
In Part 2, we'll cover Identity & Access Management, Integrations & Automation, and Auditing—the pieces that make Alpacon a complete access platform.
👉 Curious? Test it in Beta
💬 Join our Discord and share your thoughts

Rethinking Server Access: Beyond SSH

taeyeong — Thu, 25 Sep 2025 07:51:56 +0000

In the first post, we talked about how SSH was built for the 1990s.

In the second, we broke down the major problems legacy SSH creates for today’s infrastructure.

So the question is: what comes next?

Why Rethink Access?

This isn’t just about inconvenience — it’s about structural limitations.

SSH and VPN assumed only human access. IAM lived separately. Auditing was handled elsewhere.

But attacks have grown more sophisticated, systems more complex, and automation is everywhere.

We’re still trying to rely on a 1990s model in a 2025 environment.

It’s time to redefine access itself.

Introducing Websh

When we reimagined server access, we focused on eliminating the biggest weaknesses of SSH:

open ports, fragile sessions, and siloed identity and auditing.

That led us to Websh, a new protocol at the core of Alpacon’s Access Gateway.

🌐 No Open Ports

Attackers love port 22. Websh removes it completely.

Servers make outbound connections only — nothing exposed, nothing to scan.

🔒 Web-Native by Design

Every session runs over TLS (the same tech behind https://).

No VPNs. No special clients. Just stable, browser-friendly connections that survive network drops.

👥 Simple IAM & Auditing

Invite or remove teammates in seconds, with identity managed centrally.

Every action is logged and auditable, with anomalies flagged in real time.

Redefining Access

Instead of separating network access, identity, and auditing, Alpacon unifies them into a single gateway —

a platform designed for modern infrastructure and developer workflows.

👉 Want to be part of the discussion?

Join the Discord Community
Try the Beta Program

The Problem With Legacy Access

taeyeong — Wed, 24 Sep 2025 07:34:21 +0000

_In the last post, we talked about how SSH was built for the 1990s — and why it no longer fits today’s infrastructure.

But what does that really mean in practice? Let’s break it down. _

The Problems We See

Security holes: Port 22 is the first target attackers scan. A single weak point can break the whole chain.
Operational pain: Servers scattered across spreadsheets, unclear ownership, fragile onboarding/offboarding.
Automation gap: DevOps platforms, CI/CD, and AI agents all need access, but SSH was never designed for them.
Audit blind spots: Actions are not always visible or verifiable.

Meanwhile, APTs and ransomware are everywhere, and servers have become their primary targets.

The old way is no longer enough.

👉 Curious about alternatives?

Explore what we’re building in the Beta Program.
Or join the Discord Community to share your thoughts and hear from others.

SSH Was Built for the 90s. Is It Still Enough?

taeyeong — Tue, 23 Sep 2025 08:06:43 +0000

If you’ve worked with servers, you’ve probably lived inside SSH and VPNs.

For decades, they’ve been the backbone of server access.

But the truth? They’ve caused more pain than convenience.

VPN dropped mid-deploy and killed my SSH session
Onboarding a new teammate meant generating keys, sharing IPs, updating firewall rules
A 2AM production outage left only this in the logs: root executed systemctl restart…
Opening firewall ports just so GitHub Actions could reach servers

SSH was great. But it was a tool built for the 1990s.

It no longer fits today’s cloud-native, automated, AI-driven infrastructure.

👉 Want to continue the conversation?

Join our Discord and share your thoughts.

If these pain points sound familiar, we wrote more about why we believe SSH no longer fits modern infrastructure in this article:

👉 Read here

And if you’re also looking for a better way to access and manage servers, we’d love for you to try our Beta.

We’d love to hear directly from people who actually manage servers every day.
Join the Beta, share your experience, and let us know what really works. 🚀

If You Could Redesign Server Access, What Would You Build?

taeyeong — Tue, 23 Sep 2025 07:35:45 +0000

I’m genuinely curious.

For those of you managing servers day to day:

Do you find SSH still works fine for you?
Or do you run into pain points (key management, VPN drops, onboarding/offboarding, lack of auditing, etc.)?
If you could design the ideal way to access and manage servers, what would it look like?

I work at a team that’s exploring a new approach to server access.

But before anything else, I want to hear directly from the community.

What are your real frustrations?

What would make your lives easier?

We’ve also opened a Discord community where we’re talking about DevOps, security, and new ways to approach infra access.

👉 Join here

I’d love to get your perspectives and learn what matters most to you.