Start With a GitHub Project

Cloudzilla simplifies cloud deployments while giving developers the transparency and control they need. This guide provides a detailed walkthrough of the onboarding process, with technical insights for developers who want to understand the platform at a deeper level.

Step 1: Selecting Your Deployment Path

Cloudzilla provides three ways to start your deployment process:

Import an Existing GitHub Repository

This is the primary option for developers with an existing codebase. When you connect your repository, Cloudzilla integrates with your GitHub account to build and deploy your application.

Start with a Pre-Built Template

If you’re exploring the platform or don’t have a project ready, you can use one of the provided templates. These templates include pre-configured apps that Cloudzilla clones to your GitHub account and deploys automatically. It’s a fast way to get a project up and running without starting from scratch.

Add a Database

For applications that require a database, Cloudzilla currently supports MySQL. When you choose this option, the platform provisions a MySQL database for you, including automated daily backups.
Tip: If you’re new to the platform, starting with a template can help you understand the workflow without diving into a full deployment.

Step 2: Connecting Your GitHub Account

To deploy your application, Cloudzilla requires access to your GitHub repository. This integration is fundamental because the platform relies on GitHub Actions for builds. Here’s what happens during this step:

You’ll be prompted to install the Cloudzilla GitHub App, which lets you manage permissions at the repository level.
You can choose to provide access to a single repository or all repositories in your account. This flexibility is particularly useful for private repositories or if you’re working in a team environment.

Why GitHub Actions?

Cloudzilla uses GitHub Actions as the backbone of its build process. This approach ensures:

Transparency: All build logs and configurations remain within your GitHub account.
Customization: You can modify the build process directly in GitHub if needed.
Portability: The build files and Docker containers generated by Cloudzilla can be reused with other platforms like AWS ECS or Kubernetes.

What Cloudzilla Adds to Your Repository

The platform inserts a GitHub Actions configuration file into your repository. This file automates the containerization and deployment process:

On every push to your selected branch, the file triggers a new build and deploys the updated version of your app.
The configuration includes secrets for deploying to Cloudzilla. These secrets are managed securely in your GitHub repository settings and can be updated if needed.

Step 3: Framework Detection and Initial Configuration

Once you’ve connected your repository, Cloudzilla scans your project to detect the framework being used. Supported frameworks include:

Node.js
React
Next.js
Docker

If your project uses a different framework, Cloudzilla provides fallback options:

Custom Configuration: Add a Dockerfile to your repository with an EXPOSE directive that specifies the port your app listens on. This allows Cloudzilla to containerize and deploy your app without requiring framework-specific detection.

Common Scenarios

If your repository lacks a package.json or Dockerfile, Cloudzilla may not detect your framework. In this case, you can either adjust your repo structure or manually provide the necessary build and start commands during configuration.

Step 4: Setting Up Project Details

After framework detection, you’ll configure your project with the following details:

Workspace

Cloudzilla organizes projects using workspaces, which act like folders for related deployments. You can use the default workspace or create new ones for specific environments (e.g., development and production).

Branch Selection

Choose the branch you want to deploy. By default, Cloudzilla selects the primary branch (e.g., main or master), but you can also deploy secondary branches for testing purposes.

Port Configuration

Cloudzilla needs to know the port your app listens on.

This value is often framework-specific:

React and Next.js: Port 3000 by default.
Custom Frameworks: Check your app’s configuration or logs to determine the correct port.

Build and Start Commands

These are auto-populated for most frameworks:

Build Command: Used to prepare your app for deployment. For React, this might be npm run build.
Start Command: Used to launch the app. For Node.js, this could be node app.js.
You can override these defaults if your project uses custom commands.

Step 5: Configuring Environment Variables

Environment variables are essential for many applications, enabling you to configure runtime and build-time settings. Cloudzilla supports these variables through the .env format. Examples include:

API keys (e.g., for external services like Stripe or OpenAI).
Database connection strings.
Log levels (e.g., DEBUG, INFO).

When you define environment variables during setup:

Cloudzilla applies them during both the build and runtime phases.
These variables are securely stored in your GitHub repository settings, ensuring they’re only accessible by authorized processes.
Note: Use proper formatting for your variables. For example: ENV_VAR_NAME=value.

Step 6: Selecting Deployment Regions

Cloudzilla’s Adaptive Edge Engine simplifies the process of selecting deployment regions:

Instead of choosing specific data centers, you select a region (e.g., North America, Europe).
The platform dynamically places your app in the most cost-effective and performant data center within that region.

How It Works

Cloudzilla analyzes traffic patterns every five minutes, adjusting your app’s location as needed to optimize latency and cost. For example:

If traffic spikes on the US East Coast, Cloudzilla can shift your app to a nearby data center without downtime.
If a data center becomes unavailable, the platform automatically redeploys your app to a healthy location.

Step 7: Building and Deploying

Once your configuration is complete, hit Deploy. Cloudzilla handles the following behind the scenes:

Containerization: Your code is turned into a Docker container, leveraging your framework or custom Dockerfile.
Deployment: The container is deployed to the selected region with automatic SSL certification via Let’s Encrypt.

Build Logs and Debugging

Cloudzilla integrates tightly with GitHub Actions, so you can:

View detailed build logs directly in your GitHub account.
Identify issues like missing dependencies or incorrect environment variables.
Restart the build process after making changes.

Step 8: Post-Deployment Monitoring and Scaling

Once your app is live, you’ll see:

A custom URL for accessing your app.
A project dashboard showing deployment regions, traffic patterns, and logs.

Scaling Options

Horizontal Scaling: For high-traffic apps, Cloudzilla can spin up additional containers within the same region.
Multi-Region Deployment: Paid plans enable deployments in multiple regions simultaneously, ensuring global availability.

Additional Notes for Developers

Portability: The Docker containers generated by Cloudzilla are compatible with other platforms like AWS ECS, Kubernetes, and more.
Cost Optimization: Cloudzilla dynamically selects lower-cost providers, reducing your hosting expenses without compromising performance.
Transparency: Unlike many platforms, Cloudzilla gives you full access to your builds and configurations, allowing advanced users to tweak and customize as needed.

FAQs

Can I import private GitHub repos?
Absolutely! As long as Cloudzilla has the right permissions, you are good to go.

Can I change or add regions after I initially deploy my project?
Yep! You can switch or add additional regions at anytime in your project dashboard. Additional regions after your first are only $5/mo.