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.
Top comments (0)