Deploy your service on any customer cloud - Dockerfiles not required

With our current release, we have made it even more easier & faster for you to distribute your services on any cloud via On-Prem, BYOC, Self-hosted or SaaS. Read on to learn more.

To make your app portable and deploy it in different customer cloud environments, a Dockerfile is required so that the code is built as a Docker image and deployed as containers on any cloud native environment like Elastic Kubernetes Service (EKS), Google Kubernetes engine (GKE) or Azure Kubernetes service (AKS).

Last week, we made it easier to generate and publish private Kubernetes helm charts to help your team set up BYOC (Bring your own cloud) distribution channel for your business/service. This enables your enterprise end users to pull and self-host your service as a helm chart in their Kubernetes cluster running in any hosting environment. All you had to do was to link your Github repository with LocalOps while having a Dockerfile in the repository and we take care of building images & helm charts.

Today, we have released significant updates that removes one more step for developers.

🎉 You can now skip writing Dockerfiles too!

LocalOps now pulls your code from Github, builds an appropriate Docker image by inferring on the runtime used (Python, NodeJS, Go or others) and deploy them as containers appropriately in the target cloud account. 

This is huge. Because now, all of the following deployment scenarios become a 1-click process when you use LocalOps:

Deploy your EC2/Digital Ocean hosted services on any enterprise customer cloud account:

Say you have a Python/Django app hosted in a vanilla EC2 server or a DigitalOcean droplet. And you want to deploy it in your enterprise customer cloud environments as On-prem or private cloud deployment, say on Azure. 

Instead of writing a Dockerfile for each of your services and configuring them surgically to run on different cloud native environments with VMs of different architectures (x86/arm64), you can simply connect the corresponding Github code repository and let LocalOps build docker image & deploy them in your customer’s Azure account.

Get in touch with us for a quick demo and we can show you how this works.

Migrating off of EC2 to Kubernetes (EKS):

Picking on the same EC2 scenario, say you want to move the same Django app from EC2/DigitalOcean to Kubernetes (eg., EKS in AWS) for hyper scale. 

You don’t have to containerise your services or write Kubernetes yaml specs. All you have to do is to connect your codebase and cloud account with LocalOps and trigger a new deployment. LocalOps creates a Docker image for your codebase, spins up a EKS Kubernetes cluster in your AWS account and deploys those images in the same cluster. Plus, we set up a continuous deployment pipeline there, so every push on the repo results in a rolling deployment in the cluster. 

Get in touch with us for a quick demo and we can show you how this works.

Becoming cloud neutral while using services like Lambda:

Say you have Lambda functions running in AWS as part of your application or service. And you want to run the same service in a GCP (Google cloud) environment or even a bare-metal environment.

You can now run the same functions in Google cloud or bare metal server environments (enterprises love Colo and bare-metal) without making any change to the Lambda code. Once you connect your Github repo, we can dockerise and deploy the same Lambda code as a container on any Kubernetes environment across AWS, Azure, Google cloud or Bare-metal. Enabling you to become vendor neutral in minutes, without putting in much effort.

Get in touch with us for a quick demo and we can show you how this works.

This saves a huge amount of time for your team. They can focus on building your product while not writing Dockerfiles, setting up a build infrastructure for building Docker images or taking care of other day to day overheard of containerisation like image scanning, exposing relevant ports, run commands, Kubernetes specs etc.,

How it works?

We use open source Railpack under the hood. When a connected git repository doesn’t have a Dockerfile, we use Railpack automatically and make up an appropriate plan to build a docker image. With some more inputs from our platform, we make this build process more deterministic and accurate every single time. You can see the same build steps within the console in corresponding deployment logs. 

We are thrilled for what we have shipped here and there is more to come. 

Schedule a quick demo and we can show how we can help you streamline BYOC distribution for your service/business without any Dockerizing effort.

Cheers.