Developing new features for SONiC should be about solving networking problems, not waiting for builds to finish.

In many SONiC development environments, even a small control-plane change can trigger a full image rebuild, followed by booting a virtual switch and waiting for every service to initialize before validation begins. While this workflow ensures end-to-end consistency, it can significantly slow feature development, bug fixes, and iterative testing.

Fortunately, SONiC’s modular, containerized architecture enables a more efficient development model. By rebuilding only the components that change and validating them within a running SONiC environment, engineering teams can dramatically reduce iteration times without sacrificing production-aligned testing.

---

Understanding SONiC’s Containerized Architecture

One of SONiC’s defining characteristics is its microservices-based architecture. Rather than running all networking functions inside a single operating system process, SONiC separates services into independent Docker containers.

Each container is responsible for a specific function within the network operating system. Examples include routing, switch state management, telemetry, synchronization, and management services. These containers communicate through shared databases such as Redis and standardized interfaces, allowing individual services to be updated or restarted independently while maintaining overall system functionality.

This modular architecture provides more than deployment flexibility-it also enables targeted development workflows. Since services are isolated, engineers can modify a single container without rebuilding the complete SONiC image, making incremental development both practical and efficient.

---

The Four-Step Docker-First Workflow

Instead of rebuilding the entire SONiC image after every change, a Docker-first workflow focuses on running only the services required for the feature being developed. By deploying only the containers involved in a specific feature and updating only the modified package, developers can iterate much faster while preserving the same control-plane interactions used in production.

Step 1: Deploy Only the Containers Your Feature Touches

Suppose you’re developing a BGP feature that also needs to be configurable through a REST API. Instead of launching a complete SONiC instance, you only need the containers directly involved in that workflow.

A minimal development topology consists of three containers:

• database – Hosts Redis, the central control-plane datastore containing CONFIG_DB, APPL_DB, and STATE_DB. Since every SONiC service relies on these databases, this container is always required.
• bgp – Runs FRRouting (FRR), including bgpd and zebra, together with bgpcfgd, which continuously watches CONFIG_DB and generates FRR configuration automatically.
• mgmt-framework – Hosts the REST server, Translib, and YANG models responsible for writing configuration updates into CONFIG_DB.

That’s all that’s needed.

There’s no need to start syncd, pmon, SNMP, telemetry, LLDP, teamd, or even a virtual switch. By deploying only the services your feature interacts with, development environments become significantly lighter and startup times are reduced to seconds.

---

Step 2: Connect the Containers Using a Docker Bridge Network

Once the required containers are identified, they can be connected using a Docker bridge network.

Docker’s built-in DNS automatically resolves container names, allowing every service to connect to Redis simply by referencing the hostname database.

This recreates the same production control-plane workflow:

• mgmt-framework writes configuration into CONFIG_DB
• bgpcfgd detects the changes and generates FRR configuration
• bgpd immediately loads the updated configuration

Although only three containers are running, developers are exercising the exact configuration path used in a production SONiC deployment. The complete control-plane interaction is reproduced on a standard Linux development machine without requiring a full SONiC image or virtual switch.

---

Step 3: Build Only the Changed Debian Package

Rather than rebuilding the complete SONiC image, developers compile only the Debian package corresponding to the service they modified, for example:

• sonic-frr
• sonic-mgmt-framework
• A custom SONiC package

Targeted package builds typically complete in minutes instead of hours while producing the same Debian artifacts that will eventually be included in the production SONiC image.

This dramatically shortens the edit-build-test cycle during active feature development.

---

Step 4: Install the Updated Package Into the Running Container

After the package is built, it can be copied directly into the running container, installed, and the affected service restarted.

Because the container is already running, Redis is already populated, and BGP sessions are already established, developers can validate their changes almost immediately.

Instead of rebuilding an image, rebooting a virtual switch, and waiting for every SONiC service to initialize, new functionality becomes available within seconds. This significantly accelerates debugging, feature development, and iterative testing while maintaining realistic control-plane behavior.

---

Why This Approach Scales

As SONiC deployments become more sophisticated, development efficiency becomes increasingly important.

Modern data center networking projects commonly involve:

• Platform-specific SONiC customization
• Routing protocol enhancements
• gNMI and REST API integrations
• YANG model extensions
• Hardware platform enablement
• Telemetry improvements
• AI infrastructure networking enhancements

Rebuilding an entire network operating system for every incremental change becomes increasingly inefficient as project complexity grows.

A Docker-first workflow allows multiple engineering teams to work independently on different services while preserving integration with the complete control plane. Developers can spin up only the containers required for their feature, rebuild only the affected package, and validate changes against real production workflows. The result is faster development cycles, improved CI/CD efficiency, and quicker validation without compromising production accuracy.

---

Practical Considerations

Incremental development should complement, rather than replace full system validation.

Complete SONiC image builds remain essential before production releases to verify package dependencies, image composition, service initialization, upgrade behavior, and overall system stability.

A Docker-first workflow is most effective during active feature development, debugging, regression testing, and rapid iteration. Final release validation should always be performed using complete SONiC images to ensure production readiness.

Combining both approaches allows engineering teams to maximize productivity during development while maintaining confidence in release quality.

---

How PalC Networks Applies This Approach

At PalC Networks, we work extensively on SONiC customization, control-plane enhancements, and platform integrations for modern data center networks. Through these engagements, we’ve adopted a Docker-first incremental development workflow that enables faster feature iteration while preserving the same production control-plane interactions used in deployed SONiC environments.

While complete system validation remains essential before release, this incremental workflow allows day-to-day engineering to move much faster by focusing only on the components that change.