Skip to main content

Bastion Host & GitHub Actions on Hostim.dev

· 3 min read

I haven't posted updates for a while, but several core features landed on Hostim.dev recently.

Instead of shipping from a fixed roadmap, I'm following support-driven (customer-driven) development: features move to the top of the queue once users actively need them.

Over the past month, this resulted in three practical additions around Docker CI/CD, GitHub Actions deployment, and secure bastion host access.

GitHub Actions deploy for Docker apps​

Hostim.dev now supports GitHub Actions deployments out of the box.

You can trigger a deploy directly from GitHub Actions using a simple API call. This works well for common Docker CI/CD setups:

  • Build and deploy on merge to main
  • Restart an app after pushing a new Docker image
  • Manual deploys via workflow_dispatch

There's no OAuth and no hidden logic. Your workflow controls everything – branches, conditions, environments. Hostim only executes the requested action.

This is especially useful if you already run CI/CD with Docker and just want a clean deployment target.

Bastion host for secure shell access to containers​

Each project now includes a built-in SSH bastion host.

If you're unfamiliar: a bastion host is a hardened entry point used to access private infrastructure without exposing services to the public internet.

On Hostim.dev, the bastion host allows you to open a shell into running apps:

shell my-app

This answers common questions like:

  • What is a bastion host used for?
  • How do I securely SSH into containers?
  • How can I debug a production Docker app without public access?

Typical use cases:

  • Debugging production issues
  • Running database migrations
  • Inspecting environment variables
  • Accessing internal services safely

The bastion host is private, key-based, and isolated per project.

Custom commands for Docker apps​

Apps can now override the container command.

This enables common Docker patterns such as:

  • One image, multiple roles (web + worker)
  • Background jobs using the same Docker image
  • CI/CD pipelines that reuse images across environments

This pairs naturally with Docker CI/CD pipelines, where images are built once and reused consistently.

Why this approach​

Many platforms ship features based on assumptions.

Instead, these changes came directly from:

  • "How do I deploy with GitHub Actions?"
  • "How do I get shell access without exposing ports?"
  • "How do I run workers with the same image?"

Support questions shape the roadmap.

What's next​

More items are planned, but user feedback decides the order.

If something feels missing, it's probably already on the list.

👉 https://hostim.dev