Zero Code Change Deploy

Zero Code Change Deploy

Zero Code Change Deploy allows existing applications to be migrated and hosted without redesigning the source code for proprietary runtimes, immutable infrastructure, or provider-specific APIs. This simplifies movement from virtual machines to containers, migration between providers, and gradual transformation of monolithic applications into microservices.

Overview

The platform does not require developers to adopt a proprietary application runtime or make provider-specific code changes before deployment. Existing projects can be moved from traditional infrastructure to containers while retaining their original architecture and operational model.

This approach is particularly useful when:

Moving from VMs to containers Applications can be migrated without a mandatory redesign of the original codebase.
Modernizing legacy systems Traditional monolithic applications can be moved first and decomposed into microservices later.
Changing cloud providers The application is not tied to a proprietary API or runtime, which reduces vendor lock-in.
Zero code change deployment sources
Applications can be deployed through multiple standard sources and development tools.

The same zero-code-change approach supports cloud-native microservices and legacy monolithic applications based on Java, PHP, Ruby, Node.js, Python, Docker, and other supported stacks.

Application containers compared with virtual machines
Application and system containers can host both modern and traditional workloads.

Supported Deployment Options

Applications can be delivered using standard deployment methods without changing their source code for the platform.

Application Archives Deploy packages such as ZIP, TAR.GZ, WAR, JAR, EAR, and other supported archive formats.
FTPS and SFTP Transfer application files through standard secure file-transfer protocols.
Git and SVN Fetch project sources directly from a version-control repository and optionally enable automatic updates.
Development Tools Use integrated tools and plugins for Maven, Eclipse, NetBeans, IntelliJ IDEA, and similar workflows.

Reduced time to deployment

Standard deployment formats and familiar development tools lower the entry barrier, shorten migration time, and reduce dependency on a particular cloud provider.

Container Capabilities

After migration from a virtual machine, applications continue to support many familiar infrastructure operations inside containers.

  • Run multiple services inside a single container.
  • Use any required node port.
  • Attach multiple public IPv4 or IPv6 addresses to a container.
  • Write data to local or remote file systems.
  • Access containers through SSH.
  • Use configuration-management tools such as Chef or Puppet.
  • Install control panels for VPS or shared-hosting management, including cPanel, Plesk, and ISPManager.
  • Perform live migration similar to vMotion.
  • Deploy Docker Engine in a workflow comparable to virtual machines.
  • Continue other operations previously performed inside a VPS.

The platform preserves container IP addresses and hostnames after planned or unexpected downtime. Applications and connected services therefore continue using the same network references without requiring configuration rewrites.

Project Deployment with Zero Code Change

1

Click New Environment and use the topology wizard to create the required infrastructure.

Select the necessary preconfigured software stacks, such as application servers, databases, load balancers, cache nodes, and build nodes. Configure the resources, scaling limits, environment name, and region.

Create environment for zero code change deployment
Create the application topology with preconfigured software stacks.
2

After the environment is created, deploy the application using one of the supported methods:

  • Upload a prepackaged archive to the platform storage.
  • Provide a direct URL to an application archive.
  • Transfer installation files through FTPS or SFTP.
  • Fetch project sources from a Git or SVN repository.
  • Deploy through an integrated IDE or build-tool plugin.
3

Start the deployment. The platform automatically handles the infrastructure-related configuration required by the selected topology, including load-balancer integration, memory tuning, networking, SSL, and public IP settings where applicable.

4

Review any application-specific settings that depend on the new location. In most cases, source-code changes are not required. Only values such as IP addresses, domains, database endpoints, or custom file paths may need to be updated.

Server configuration files are available through the built-in File Manager in the dashboard.

!

Application-specific configuration

Zero Code Change means the application does not need to be redesigned for the platform. Configuration values tied to the previous infrastructure may still require adjustment after migration.

Migration Result

Using this workflow, an application can be moved from another cloud, VPS, or virtual machine to the platform without introducing a provider-specific runtime or rewriting the application architecture.

No mandatory redesign The existing project structure and source code can be retained.
Familiar deployment tools Standard archives, repositories, transfer protocols, IDEs, and build systems remain usable.
Reduced vendor lock-in Applications are not dependent on proprietary APIs or runtimes.
Smooth modernization Legacy applications can be migrated first and modernized incrementally after deployment.

Expected result

The application is deployed to the selected container topology using its existing codebase and standard deployment method, with only location-dependent configuration updated where necessary.