CODESYS 4 vs CODESYS 3: What the 1.0 Web IDE Changes

Last Updated: September 24, 2026

CODESYS 4 version 1.0.0.0 shipped in September 2026, and CODESYS calls it approved for production use, not a beta. The headline is a browser-technology IDE that runs on Windows, Linux x64 and Linux ARM64. The more important change is underneath: projects are folders of text files, dependencies are pinned in a lock file, and a headless command line can build a signed library on a pipeline server. So the real question in CODESYS 4 vs CODESYS 3 is not “which editor is nicer”. It is “which parts of my PLC engineering workflow can move to a Git-native toolchain today, and which must stay on the incumbent”. The answer in 1.0 is narrow and specific. Library development and small Modbus TCP machines qualify. Commissioning, motion, visualization, safety and most fieldbuses do not. This guide explains the mechanics, the compatibility rules, the gaps, and a decision process you can apply project by project.

What this covers: the shared-compiler architecture, the folder-based project format and lock files, a side-by-side decision matrix, a worked library CI/CD pipeline, the four operating modes, a migration runbook, and the failure modes that will bite early adopters.

Context and Background

CODESYS Development System 3 has been the default IEC 61131-3 engineering tool for a large share of the controller market for two decades. CODESYS itself cites more than 20 years of history and over 300,000 users. Hundreds of hardware vendors ship its runtime inside their PLCs, drives and edge boxes, which is why a change to the CODESYS toolchain ripples across the industry. We compared its runtime model against Beckhoff’s in our CODESYS vs TwinCAT soft PLC comparison, and that runtime layer is exactly what CODESYS 4 leaves untouched.

CODESYS 3 is a Windows desktop application. Historically it stored a project as a single binary file, which made Git diffs useless and merges impossible. The vendor has been closing that gap from inside CODESYS 3 as well. Service Pack 22 (version 3.5.22.0, March 24, 2026) introduced File-Based Storage as a 0.9.0.0 preview for the Professional Developer Edition, along with an MCP add-on and SARIF export from Static Analysis. File-Based Storage 1.0.0.0 followed on August 6, 2026, with a new file format, normalized line endings for Git, compatibility with CODESYS Git V2.0.0.0, and a read-only mode that works without a license. The Development System MCP Server 1.1.0.0 arrived on July 22, 2026.

CODESYS 4 has a longer back story. It was announced in May 2023, and field testing of the first version was planned from April 2026, according to an interview with Kevin Ketterle, Head of Web Based Platforms. On August 12, 2026, CODESYS released RISC Front End 4.0.3.0 with the note “Enable usage of codegenerators for ARM architecture in CODESYS 4”, a small but telling sign that shared compiler components now ship for both tools.

The key positioning statement on the official CODESYS 4 product page is blunt: “Same compiler, same runtime system, same libraries. New user interface.” CODESYS 4 is a second programming system that sits alongside CODESYS 3. It does not replace it. Both are developed and maintained in parallel, and there is no set date for phasing out CODESYS 3.

The Architecture: Same Compiler, New Shell

CODESYS 4 keeps the CODESYS 3 compiler, runtime and libraries, and replaces the desktop shell with a background process plus a web-technology UI. Projects become folders of JSON, XML and text; dependencies are pinned in a lock file; a headless c4 CLI builds libraries and boot applications. The runtime target must be Control SL at V3.5 SP19 or later.

That one-paragraph answer hides three design decisions, each with consequences for how teams work. Figure 1 shows how the pieces fit.

Figure 1: CODESYS 4 and CODESYS 3 are two front ends over a shared compiler, library set and runtime connection path.

The CODESYS 4 UI talks only to a background process. That process owns compilation, project management and controller communication. It reads and writes a plain project folder, calls the same compiler that CODESYS 3 uses, and reaches controllers through the CODESYS Gateway. CODESYS 3 uses the same compiler and the same gateway path, but keeps its own project storage. The outputs, compiled libraries or boot applications, are consumable by both.

A background process and a thin UI

CODESYS 4 separates the engine from the view. A background process compiles, manages the project and talks to controllers, and the UI only renders results. “Web-based” describes the UI technology, not the deployment model. CODESYS states plainly that CODESYS 4 is not a cloud service, not subscription software, runs fully inside your own network, and needs no Internet connection. On Windows the UI opens in its own application window, so users never see a separate browser.

This split is what makes the rest possible. Once the engine is a process with a defined interface, three things follow naturally. It can run on Linux x64 and Linux ARM64 as well as Windows x64, without a virtual machine. It can run with no UI at all, as a command that does one job and exits. And it can run as a multi-user server where each browser session maps to its own isolated engine process.

Compare that with CODESYS 3, where the engine and the UI live in one Windows desktop process. Automating CODESYS 3 has traditionally meant driving that Windows application through its Python scripting interface, which can run without a visible UI but still needs the full IDE installed. That is why Linux-based CI runners and CODESYS 3 have always been awkward partners. Teams ran Windows build agents, often VMs with a licensed IDE installed, just to compile a library.

A project is a folder, not a binary file

CODESYS 4 stores each project as a directory. A library project uses the .fbslib extension, a device project uses .fbsdev, and a workspace uses .fbsws. Inside, content is JSON, XML and plain text. The product page states there is “no proprietary binary format.”

The practical effect is that Git works the way software teams expect. A change to one function block changes one file, and a reviewer sees a line-level diff. Two engineers editing different POUs (Program Organization Units, the IEC 61131-3 term for programs, function blocks and functions) produce changes that merge cleanly. Blame, bisect and code review all become meaningful for PLC code.

This is also where the comparison is closer than the marketing suggests. CODESYS 3’s File-Based Storage 1.0.0.0 gives CODESYS 3 users a text-based, Git-friendly layout too. Library projects stored with CODESYS 3 File-Based Storage open in CODESYS 4, and vice versa. So “Git support” alone is not a reason to switch. The differentiators sit elsewhere, as the next sections show.

Dependencies are declared and locked

CODESYS 4 introduces explicit dependency management borrowed from mainstream software ecosystems. A Libraries.json file declares what a project needs, and can use open ranges such as 3.5.*. A Libraries.lock.json file records the fully resolved dependency tree, with exact versions and SHA384 checksums. Versions follow semantic versioning, including pre-release marking.

Why does a lock file matter for a PLC? Consider a machine builder with 40 machine variants that all consume an in-house motion-helpers library. Without a lock, “rebuild variant 17 from last year” depends on which library versions happen to be installed on the engineer’s PC. With a lock file committed next to the project, the build resolves the same tree every time, and a checksum mismatch fails loudly rather than silently compiling against a different binary. That is reproducibility, and it is the property auditors and functional-safety processes keep asking for.

The CLI exposes the dependency operations directly: install, restore, resolve and check. In a pipeline, restore rebuilds exactly what the lock file says, and check can gate a merge request if someone edits Libraries.json without regenerating the lock.

Side by Side: The Decision Matrix

The table below compares the two tools on the dimensions that decide real projects. Everything in the CODESYS 4 column refers to version 1.0.0.0.

Dimension	CODESYS 3 Development System	CODESYS 4 1.0.0.0
Role	Full engineering and commissioning suite	Second programming system for defined use cases
Host platforms	Windows desktop	Windows x64, Linux x64, Linux ARM64
Project storage	Project file; File-Based Storage 1.0 option since Aug 2026	Folder of JSON, XML, text (.fbslib, .fbsdev, .fbsws)
Dependency management	Library manager with installed repository	Libraries.json plus Libraries.lock.json with SHA384 checksums
Headless build	Python scripting of the Windows IDE	c4 / c4-cli on all three platforms
Multi-user server	No	c4-server with PAM, Linux groups, LDAP
Languages	All IEC 61131-3 languages plus CFC	Structured Text; Ladder editor 0.1
Fieldbus and I/O	Broad fieldbus set, motion, visualization, safety	Modbus TCP configurator for small I/O counts; Raspberry Pi GPIO
Online change, breakpoints, forcing	Yes	Not in 1.0
Refactoring, cross-references, project-wide undo	Yes	Not in 1.0
Test Manager, Static Analysis	Available as add-ons	Not in 1.0
Supported targets	Control SL and hundreds of OEM devices	Control SL runtimes only, V3.5 SP19 or later
Release model	Annual Service Pack plus patches	Whole versions every 6 to 8 weeks, medium-term target
Price	Existing licensing model	Free through end of 2028

Read the matrix row by row and a pattern emerges. CODESYS 4 wins on every row that concerns build infrastructure: platforms, storage, dependencies, headless builds and servers. CODESYS 3 wins on every row that concerns the machine itself: languages, fieldbuses, debugging, testing and device coverage. That split is the heart of the adoption decision.

The thesis: CODESYS 4 1.0 is a build toolchain with an IDE attached

Most coverage frames CODESYS 4 as “a web IDE”. That undersells what matters and oversells what exists. The ST editor is capable, with syntax highlighting, auto-complete, hover tooltips and inline variable monitoring. But without online change, breakpoints, forcing, refactoring or cross-references, it cannot replace CODESYS 3 as a daily engineering environment for a real machine.

What 1.0 can replace is the fragile Windows build VM. The combination of folder projects, lock files, a headless CLI on Linux, and signed compiled libraries that CODESYS 3 can consume is a complete library supply chain. The adoption unit for CODESYS 4 in 2026 is therefore the library, not the machine. Teams that treat it as a pipeline component will get value immediately. Teams that expect to move commissioning over will hit a wall within a day.

Walk-through: A PLC Library CI/CD Pipeline

The first of the two officially supported productive use cases is library development in Structured Text and Ladder with automated builds. CODESYS documents the workflow, and its official webinar demonstrated it with a GitLab pipeline. Figure 2 traces the flow.

Figure 2: A tag-triggered library pipeline. The runner restores locked dependencies, builds headlessly and publishes a signed compiled library.

The developer can work in CODESYS 4 (“Scenario B”), or keep developing and testing in CODESYS 3 with File-Based Storage and use CODESYS 4 only for the automated build, which CODESYS calls “Scenario A”. The library folder is committed to Git and reviewed through normal merge requests with line-level diffs. When a release is tagged, the pipeline runner restores dependencies from the lock file and runs the headless library build. The output is a signed .compiled-library artifact, which contains no source and works in both CODESYS 3 and CODESYS 4 device projects. The pipeline notifies the team by email or chat.

Step by step

1. Structure the repository. One library per repository, or a monorepo with one .fbslib folder per library. Commit Libraries.json and Libraries.lock.json beside the project.
2. Lock dependencies locally. Run the resolve step on a developer machine, review the lock diff, and commit it. A lock change is a reviewable event, exactly like a package-lock.json change in a web project.
3. Gate merges. On every merge request, run the dependency check and a compile. A failing compile blocks the merge.
4. Tag to release. Use semantic version tags. CODESYS 4 supports marking pre-release versions, so a tag such as 1.4.0-rc.1 is a natural fit. Check how your tag format maps onto the library version fields before automating it.
5. Build headlessly. The runner calls c4 library save-compiled (the fact that c4 runs a task and exits is what makes this CI-friendly). c4-cli library pack produces a source archive if you also want to archive source.
6. Sign and publish. Sign the compiled library and push it to wherever your device-project teams consume libraries.
7. Notify. Post the version and changelog to the team channel.

A minimal pipeline definition looks like the sketch below. The command names come from CODESYS documentation; the arguments, paths and job layout are illustrative placeholders, so check the CLI reference shipped with your installation before copying them.

# .gitlab-ci.yml  (illustrative sketch; verify arguments against the c4-cli reference)
stages: [check, build]

check-deps:
  stage: check
  tags: [linux-arm64]          # any Linux x64 or ARM64 runner with CODESYS 4 installed
  script:
    # restore and check are documented dependency commands; exact subcommand path is illustrative
    - c4-cli library restore <path-to-.fbslib>     # placeholder arguments
    - c4-cli library check   <path-to-.fbslib>
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

release-build:
  stage: build
  tags: [linux-arm64]
  script:
    - c4-cli library restore       <path-to-.fbslib>
    - c4-cli library save-compiled <path-to-.fbslib>   # produces .compiled-library
    - c4-cli library pack          <path-to-.fbslib>   # optional source archive
    - ./sign-and-publish.sh                            # your signing and upload step
  artifacts:
    paths: ["out/"]
  rules:
    - if: $CI_COMMIT_TAG

Why this is a genuine step change

Three properties make this pipeline different from what most CODESYS 3 shops run today.

First, the runner is Linux. It can be an ARM64 box or a standard x64 container host, and it needs no Windows VM. For a team already running GitLab or GitHub runners on Linux, CODESYS builds stop being a special snowflake.

Second, in version 1.0 no separate license is required for the pipeline machine. For many teams the licensed build VM was the single most expensive and most neglected piece of the toolchain. Removing the license question removes the reason to keep only one build agent.

Third, reproducibility is enforced by the lock file rather than by discipline. Because the lock file pins a SHA384 checksum per library, a tampered or accidentally replaced library should be caught at restore time rather than silently compiled in. That is a meaningful supply-chain control for PLC code, and it aligns with how the IT side already secures dependencies. If your organisation manages controller configurations declaratively, this pipeline slots in naturally in front of the deployment patterns we covered in our GitOps tutorial for industrial fleets with Argo CD and Flux.

A worked example: time saved per release

The following is an estimate, not a measured benchmark; no independent build-time data for CODESYS 4 exists yet. Suppose a team releases a shared library twice a month. The manual CODESYS 3 routine is: boot the build VM, pull the source, open the IDE, check library versions, compile, save as compiled library, sign, copy, announce. Assume 45 minutes of engineer attention per release, including the occasional “wrong library version installed” investigation.

Twice a month is 24 releases a year. 24 × 45 minutes = 1,080 minutes, or 18 engineer-hours a year per library. With a tag-triggered pipeline, attention drops to perhaps 5 minutes per release for review of the notification, so 24 × 5 = 120 minutes, or 2 hours. For a team maintaining 10 shared libraries, the estimated saving is (18 − 2) × 10 = 160 engineer-hours a year. Your numbers will differ, but the shape holds. The bigger gain is qualitative: releases become boring, so teams release smaller changes more often.

The Four Operating Modes

CODESYS 4 runs in four modes, all using the same engine. Figure 3 shows how they relate.

Figure 3: Four deployment topologies over one engine. Server mode gives each session its own OS process and Linux user.

Single-user Windows. A standard .exe installer; the UI opens in its own window. This is the drop-in experience for an engineer who wants to try CODESYS 4 next to CODESYS 3.

Single-user Linux. A Debian package for x64 or ARM64; the UI opens as a local browser session. For CODESYS’s own engineering tool, this is the first native Linux option; CODESYS 3 users on Linux have typically needed a Windows VM.

Shared team server. c4-server runs on Linux x64 or ARM64 and manages logins and sessions based on local Linux users and groups, with LDAP available via PAM (Pluggable Authentication Modules). Each session is its own OS process, and permissions follow Linux user management. CODESYS notes that the server can even run directly on a control system.

Headless automation. c4 runs a task and exits. Use it in scripts, cron jobs and CI pipelines.

Security mechanics of server mode

Server mode is where a web UI raises legitimate security questions, and CODESYS has made several architectural choices worth understanding. Authentication, request rate limiting and process isolation are built into the architecture rather than bolted on. One process per session means a crash or compromise in one engineer’s session does not share memory with another’s. Linux file permissions govern which projects each user can read, so you reuse the access model your IT team already audits.

The channel between the UI and the backend is protected against CSRF (cross-site request forgery), and hosted setups use TLS. The minimum runtime version matters here too. CODESYS 4 requires runtimes at V3.5 SP19 or later because SP19 introduced runtime user management, and insecure legacy protocols were deliberately not reimplemented. Connections go through the CODESYS Gateway.

Where server mode fits, and where it does not

A shared server suits a test bench lab, a training room, or a small team that wants every engineer on the same tool version. It also suits the “engineer from any laptop” pattern, since the only client requirement is a browser inside the network.

Running the server on a control system is technically supported, but treat it with care. An engineering server on the same box as a running controller shares CPU, memory and attack surface with the real-time workload. For a Raspberry Pi test bench, that is acceptable. For a production cell, keep engineering and control on separate hosts, which is consistent with the zone-and-conduit thinking in IEC 62443.

Compatibility Rules and Migration Runbook

Before migrating anything, internalise the compatibility rules, because they are asymmetric.

• Library projects cross over. Library projects stored with CODESYS 3 File-Based Storage open in CODESYS 4, and CODESYS 4 library projects open in CODESYS 3.
• Device projects do not cross over. A CODESYS 3 device project does not open in CODESYS 4, and vice versa. A conversion tool is planned but is not in 1.0.0.0.
• Compiled output crosses over. A .compiled-library built by CODESYS 4 works in CODESYS 3 projects, and code compiled by CODESYS 4 runs on any controller that already executes CODESYS 3 code, subject to the runtime minimum.
• Runtime minimum is V3.5 SP19. Older runtimes are out of scope.
• Targets are Control SL only. In 1.0.0.0, CODESYS approves only its own Control SL runtimes for project engineering. The list covers Control for Raspberry Pi (MC SL, SL, 64 SL), Windows soft PLCs (Control Win V3, Win V3 x64, RTE V3, RTE V3 x64), Linux (Linux ARM SL, Linux ARM64 SL, Linux SL) and Virtual Control for Linux (ARM SL, ARM64 SL, SL). Third-party OEM devices are technically possible but not guaranteed. OEMs are expected to ship “CODESYS 4 Content Extensions”, likely installable from version 1.1.0.0, which is not a committed date.

The mixed workflow is explicitly allowed. You can develop in CODESYS 4 and commission in CODESYS 3. In practice, given the device-project rule, that means libraries flow from CODESYS 4 into CODESYS 3 device projects, and the CODESYS 3 device project remains the commissioning artifact.

Migration runbook for a library team

1. Inventory. List every shared library, its consumers, and the runtime versions of the controllers those consumers target. Flag any consumer below V3.5 SP19. CODESYS 4 cannot engineer those controllers, so their device projects stay on CODESYS 3 regardless, and you should test any CODESYS 4-built library in those projects before assuming it behaves identically.
2. Move libraries to text first. Convert each library to CODESYS 3 File-Based Storage 1.0 inside CODESYS 3. This step is reversible and gives you Git diffs immediately, even before CODESYS 4 enters the picture.
3. Open in CODESYS 4. Open the File-Based Storage library in CODESYS 4 and confirm it compiles. Differences here usually point to language features or editors that 1.0 does not yet cover.
4. Add the manifest and lock. Declare dependencies in Libraries.json, resolve, and commit Libraries.lock.json.
5. Stand up a Linux runner. Install CODESYS 4 on an x64 or ARM64 Linux runner and reproduce a local build headlessly.
6. Run both pipelines in parallel for one release. Build the library the old way and the new way, then compare behaviour in a CODESYS 3 consumer project on a test controller.
7. Switch the source of truth. Once the outputs match in behaviour, make the tag-triggered pipeline the only release path and retire the build VM.
8. Keep testing in CODESYS 3. Test Manager still needs CODESYS 3, so keep a CODESYS 3 VM for automated tests until CODESYS 4 gains a test story.

For teams exploring containerised control as the next step, the architectural direction here pairs well with the patterns in our piece on software-defined manufacturing with virtual PLCs and containers, since Virtual Control for Linux is on the approved target list.

Who Should Switch: The Decision Tree

The second supported productive use case is small device projects that use Modbus TCP, such as small machines and test benches. Everything else stays in CODESYS 3 for now: other IEC 61131-3 languages, other fieldbuses, visualization, motion and safety. Figure 4 turns those rules into a decision process.

Figure 4: Apply this per work item, not per company. Most organisations will end up with a mix.

Start with the work item, not the organisation. If it is a library written in Structured Text or Ladder, build it with the CODESYS 4 CLI regardless of where you edit it. If it is a device project, it qualifies for CODESYS 4 only if three things hold. It is a small Modbus TCP machine, it targets an approved Control SL runtime at SP19 or later, and it does not need online change or forcing during commissioning. If automated tests or static analysis are part of your quality gate, keep those in CODESYS 3 for now.

Profiles that fit CODESYS 4 1.0 today

• Library and platform teams in machine builders and system integrators who maintain shared function-block libraries for many projects.
• Test bench builders using a Raspberry Pi or Linux industrial PC with Modbus TCP remote I/O.
• Education and training labs that want one shared server on Linux and no per-seat Windows installs.
• Linux-first engineering teams that have kept a Windows VM alive purely for CODESYS.

Profiles that should wait

• Commissioning engineers who need online change, breakpoints, forcing and Ladder power flow at runtime.
• Motion, HMI and safety projects. SoftMotion and visualization are on the roadmap. Ketterle names EtherCAT as the next priority, calling it the second most popular fieldbus after Modbus, with visualization and SoftMotion also named. No timing is committed.
• OEM hardware users whose controllers are not Control SL; wait for Content Extensions.
• Teams whose quality gate depends on Test Manager or Static Analysis inside the build.

If you are weighing a completely different path, such as an open-source runtime, our OpenPLC Runtime v4 vs v3 migration guide covers a toolchain that made a similar architectural jump toward headless, API-driven operation, with very different maturity and support trade-offs.

Trade-offs, Gotchas, and What Goes Wrong

The release cadence is a double-edged sword. CODESYS 4 ships whole new versions (1.0.0.0, 1.1.0.0 and so on) with no Service Packs or patches. Fixes arrive in the next version, with a medium-term target of 6 to 8 weeks. By estimate, that is 52 ÷ 8 ≈ 6.5 to 52 ÷ 6 ≈ 8.7, so roughly six to nine versions a year. CODESYS 3, by contrast, shipped SP22 on March 24, 2026 and then patches 3.5.22.10 (April 2), 3.5.22.20 (May 20) and 3.5.22.30 (July 23). If a CODESYS 4 bug blocks you, there is no hotfix channel; you wait or you work around it. Pin the CODESYS 4 version on your runners and upgrade deliberately.

Device projects are a one-way door, for now. Device projects do not open across environments, and the converter has not shipped. So starting a device project in CODESYS 4 commits that project to CODESYS 4’s current feature set. If a customer later needs a feature only CODESYS 3 has, you rebuild the device project there. Keep libraries portable and device projects thin.

Debugging gaps change how you commission. No online change, no breakpoints and no variable write or force means CODESYS 4 cannot be your commissioning tool in 1.0. Inline variable monitoring helps with observation, but not with intervention. Plan commissioning in CODESYS 3 from day one.

Refactoring gaps hurt at scale. Without refactoring, a cross-reference list or project-wide undo, large library codebases become harder to reshape inside CODESYS 4. The workaround is to lean on Git: small commits, branches for risky changes, and reviews that catch rename fallout.

OEM hardware is the silent blocker. Many plants run CODESYS on vendor controllers, not Control SL. Until Content Extensions ship, “technically possible, not guaranteed” is not a basis for production use.

Ladder is at version 0.1. The Ladder editor offers basic offline functions based on the CODESYS 3 graphical editor. Teams whose libraries are Ladder-heavy should validate carefully before relying on it.

Pricing beyond 2028 is unannounced. CODESYS says CODESYS 4 is free to use through the end of 2028. Professional Developer Edition customers (the bundle with CODESYS Git and CODESYS MCP Server) get CODESYS 4 included with no additional long-term cost. For everyone else, the price after 2028 has not been announced, so factor that into multi-year tooling plans.

No performance data yet. There are no independent benchmarks of CODESYS 4 build times, memory use or UI responsiveness. Measure on your own libraries before promising build-time improvements.

Practical Recommendations

Treat CODESYS 4 1.0 as infrastructure first and as an editor second. The fastest return comes from moving library builds onto Linux runners with locked dependencies, while leaving every machine-facing workflow in CODESYS 3. That split captures the reproducibility, cost and automation gains without betting commissioning on a 1.0 tool.

Adopt in three waves. In wave one, convert libraries to File-Based Storage in CODESYS 3 and get them into Git. In wave two, add lock files and a headless CODESYS 4 pipeline. In wave three, pilot a small Modbus TCP test bench as a CODESYS 4 device project. Revisit the scope every few releases, since the 6-to-8-week cadence means the gap list will shrink quickly, but only act on features that actually ship.

Checklist

• [ ] List shared libraries, their consumers and target runtime versions; confirm V3.5 SP19 or later.
• [ ] Confirm every target is an approved Control SL runtime, or park it until Content Extensions arrive.
• [ ] Convert libraries to CODESYS 3 File-Based Storage 1.0 and commit to Git.
• [ ] Add Libraries.json, resolve, and commit Libraries.lock.json.
• [ ] Install CODESYS 4 on a Linux runner and pin its version.
• [ ] Build one library headlessly with c4 library save-compiled and sign the output.
• [ ] Validate the compiled library in a CODESYS 3 consumer project on a test controller.
• [ ] Keep a CODESYS 3 environment for commissioning, Test Manager and Static Analysis.
• [ ] Decide server mode placement: separate host for production cells.
• [ ] Put a review date in the calendar to reassess after each CODESYS 4 release.

Frequently Asked Questions

Does CODESYS 4 replace CODESYS 3?

No. CODESYS positions CODESYS 4 as a second programming system that runs alongside CODESYS Development System 3. Both are developed and maintained in parallel, and CODESYS has set no date for phasing out CODESYS 3. In version 1.0.0.0, CODESYS 4 supports two productive use cases: library development with automated builds, and small Modbus TCP device projects. Commissioning, motion, visualization, safety and most fieldbuses remain CODESYS 3 territory. Most organisations should expect to run both tools for several years and assign work to each based on the task.

Is CODESYS 4 a cloud or subscription product?

No. The “web-based” label refers only to the UI technology. CODESYS states that CODESYS 4 is not a cloud service and not subscription software. It runs entirely inside your own network, and it needs no Internet connection. On Windows it opens in its own application window, and on Linux it opens a local browser session. For teams, the optional c4-server runs on your own Linux x64 or ARM64 host, authenticates against local Linux users or LDAP through PAM, and gives every session its own isolated operating system process.

Can CODESYS 4 projects run on my existing controllers?

Code compiled by CODESYS 4 runs on controllers that already execute CODESYS 3 code, provided the runtime is V3.5 SP19 or later. SP19 is the floor because it introduced runtime user management, and CODESYS did not reimplement insecure legacy protocols. In 1.0.0.0, only CODESYS Control SL runtimes are approved for project engineering, including Raspberry Pi, Windows soft PLC, Linux and Virtual Control for Linux variants. Third-party OEM controllers are technically possible but not guaranteed until vendors ship CODESYS 4 Content Extensions, expected from roughly version 1.1.0.0.

Can I open a CODESYS 3 project in CODESYS 4?

It depends on the project type. Library projects stored with CODESYS 3 File-Based Storage open in CODESYS 4, and CODESYS 4 libraries open in CODESYS 3. Device projects do not open across the two environments. CODESYS has said a conversion tool is planned, but it is not part of 1.0.0.0. The practical pattern is to share libraries in both directions, and to keep existing device projects in CODESYS 3. Compiled libraries produced by CODESYS 4 can be consumed directly by CODESYS 3 device projects.

How much does CODESYS 4 cost?

CODESYS says CODESYS 4 is free to use through the end of 2028. Customers with the Professional Developer Edition, which bundles CODESYS Git and the CODESYS MCP Server, get CODESYS 4 included with no additional long-term cost. Pricing for other users after 2028 has not been formally announced, so treat it as an open question in multi-year budgets. In version 1.0, the headless CLI also needs no separate license on a pipeline machine, which removes a common cost behind dedicated Windows build agents for CODESYS 3.

What is missing from CODESYS 4 1.0?

Version 1.0.0.0 has no online change, breakpoints, variable write or force, or Ladder power-flow display at runtime, so CODESYS 3 remains the commissioning tool. It also lacks refactoring, a cross-reference list and project-wide undo and redo. Test Manager, Static Analysis, automated unit tests and library documentation generation are absent, and third-party partner editors and configurators are not available. Language support covers Structured Text plus a version 0.1 Ladder editor. EtherCAT, visualization and SoftMotion are named roadmap priorities, but CODESYS has not committed to dates.

Further Reading

• CODESYS vs TwinCAT: soft PLC runtime comparison for the runtime layer CODESYS 4 leaves unchanged.
• Software-defined manufacturing with virtual PLCs and container control for where Virtual Control for Linux fits.
• OpenPLC Runtime v4 vs v3: architecture changes and migration for an open-source toolchain on a similar headless path.
• Argo CD and Flux GitOps tutorial for industrial fleets for deploying pipeline outputs declaratively.
• CODESYS 4 official product page for positioning, operating modes and the 1.0.0.0 scope.
• CODESYS releases and updates for File-Based Storage, Development System patches and RISC Front End release notes.

By Riju — about