Petr Ankudinov wrote an excellent comment about netlab Fast cEOS Configuration implementation. Paraphrasing the original comment:

If the use case is the initial lab deployment, why don’t you use containerlab startup-config option to change the device’s startup configuration?

I have to admit, I’m too old to boldly go with the just use the startup configuration approach. In ancient times, Cisco IOS did crazy stuff if you rearranged the commands in the startup configuration. But ignoring that historical trivia (Cisco IOS/XE seems to be doing just fine), there are several reasons why I decided to use the startup configurations (and you can use them with some containers) as the last resort:

• While you can use partial startup configurations for most devices for which containerlab supports startup-config parameter, containerlab can give Arista cEOS only complete startup configuration. That would require netlab to reimplement the initial device configuration that is now managed by containerlab.
• None of the devices I tested produce easily-observable error messages when there are errors in startup configurations; they usually generate messages that appear in container logs along with all other boot-related chaff. The outputs (including error messages) of FastCLI-based Linux scripts are easy to capture in the calling process (netlab initial) that displays them to the user.
• netlab initial uses docker exec to execute Linux scripts within the containers, and automatically receives the exit status of the executed Linux scripts, making it trivial to detect configuration errors. I found no similar mechanism for startup configurations.
• netlab configures individual device features with independent configuration snippets. You might get unexpected side effects when combining multiple snippets into a single configuration file if the same command happens to be valid in multiple configuration contexts, and the configuration snippets are arranged in just the right way to make the two conflicting parts adjacent.

Finally, we need a mechanism to deploy ad-hoc configurations anyway (using the netlab config command), and it’s simpler to use a single fast configuration mechanism (when available) than a combination of several mechanisms.