Troubleshooting with Bunnyshell
Things break. Containers crash, builds fail, and services refuse to start. Knowing how to quickly diagnose and fix issues in Bunnyshell is just as important as knowing how to deploy. Watch the video above for a concise walkthrough of the key troubleshooting tools and techniques built into the platform.
Reading Build Logs and Component Status
The first place to look when something goes wrong is the component status in your Bunnyshell dashboard. Each component in your environment shows a real-time status indicator — running, building, error, or pending. When a component enters an error state, clicking on it reveals the build and runtime logs.
Build logs show the output of your Docker build process. Common issues here include missing dependencies, syntax errors in a Dockerfile, failed package installations, or exceeded memory limits during compilation. The logs are streamed in real time during deployment, so you can watch the build as it happens and catch failures early.
Runtime logs show the standard output and standard error of your running container. If your application starts but then crashes, this is where you will find the stack trace, unhandled exceptions, or misconfiguration errors. Bunnyshell retains logs from previous container instances as well, so even if a container has restarted several times due to a CrashLoopBackOff, you can review the logs from each attempt.
The environment events timeline is another powerful diagnostic tool. It shows a chronological list of every operation that has occurred in the environment — deployments, restarts, scaling events, and errors. This timeline is invaluable when you need to understand the sequence of events that led to a problem, especially in multi-component environments where one service's failure can cascade to others.
SSH Access and Port Forwarding
Sometimes logs are not enough. You need to get inside the container and look around. Bunnyshell provides SSH access to running containers directly from the dashboard or the CLI. This lets you inspect the filesystem, check environment variables, verify that configuration files were mounted correctly, or run diagnostic commands like curl to test connectivity between services.
Port forwarding is equally useful for troubleshooting. If a service is listening on a port inside the container but not responding to external requests, you can forward that port to your local machine to test it directly. This helps isolate whether the issue is with the application itself or with the networking and ingress configuration.
To SSH into a container, use the Bunnyshell CLI: bns components ssh --component <name>. For port forwarding, the CLI offers bns components port-forward which maps a remote port to a local one. Both tools work without any additional configuration — Bunnyshell handles the secure connection through its control plane.
When to Restart vs. Redeploy
A common question is whether to restart a component or do a full redeploy. The answer depends on the nature of the problem.
Restart when the issue is transient. A database connection pool that got exhausted, a process that hung due to a deadlock, or a temporary upstream service outage — these are all cases where restarting the container with the same image will likely fix the problem. A restart is fast because it does not rebuild anything; it simply stops the container and starts a new instance from the existing image.
Redeploy when the issue is in the code or configuration. If you have pushed a fix to a bug, updated an environment variable, or changed a Dockerfile, you need a redeploy. This triggers a full rebuild of the container image from source and deploys the new version. Redeploying takes longer but ensures you are running the latest code.
As a rule of thumb: if the same error occurs after a restart, a redeploy is almost certainly needed. And if the same error persists after a redeploy, the issue is in the application code itself — time to check your source, dependencies, and configuration files.
Ship faster starting today.
14-day full-feature trial. No credit card required. Pay-as-you-go from $0.007/min per environment.
Frequently Asked Questions
How do I check why my container keeps crashing in Bunnyshell?
Start by checking the component status and build logs in the Bunnyshell dashboard. Look for exit codes — an OOMKilled status means the container ran out of memory, while a CrashLoopBackOff usually indicates the application is failing on startup. You can also SSH into the container to inspect files, check environment variables, or run diagnostic commands directly.
When should I restart a component versus redeploying it?
Restart when the issue is transient — a temporary network glitch, a stuck process, or a database connection timeout. Redeploy when the issue is in the code or configuration — a missing environment variable, a broken build, or an updated dependency. Restarting reuses the existing container image, while redeploying rebuilds from source.
Can I access logs for containers that have already crashed?
Yes. Bunnyshell retains logs from previous container instances, so you can review what happened before the crash. The environment events timeline also shows a chronological record of all operations, deployments, and errors, which is useful for understanding the sequence of events that led to a failure.