Our colleague Andrija Vojnović, Lead DevOps Engineer at CYBERLAB, will be speaking at AWS Community Day Adria 2026, taking place on October 22 in Ljubljana, Slovenia.

One Firewall to Rule Them All:

Our colleague Andrija Vojnović, Lead DevOps Engineer at CYBERLAB, will be speaking at [AWS Community Day Adria 2026](https://awscommunityadria.com/sessions/ljubljana-1262316/), taking place on October 22 in Ljubljana, Slovenia.

His talk, "One Firewall to Rule Them All: Hub & Spoke on AWS," is scheduled for 11:30 in the Fabiani room and runs for 30 minutes.

## What It's About?

The session looks at how a Hub and Spoke architecture helps teams manage network complexity as AWS environments grow, from a single VPC to multiple VPCs spread across an AWS Organization. Andrija will walk through using AWS Cloud WAN as the global backbone tying regions together with a single declarative policy, and how to centralize traffic inspection, covering egress, ingress, and east-west traffic between spokes. 

## Why It's Worth Attending?

Expect concrete design trade-offs rather than a marketing pitch: where to place inspection, why egress inspection often stays regional even on a global network, and when centralization is actually worth the cost.

## Catch the Talk

If you're at AWS Community Day Adria, catch Andrija's talk! 


Hub & Spoke on AWS

Hands-on SuperPlane review: we built two opposite DevOps workflows on DigitalOcean to test guardrails, approvals, and alerting. Here's what held up.

SuperPlane Review:

> **Editor’s note:** This review is based on testing conducted in July. The product has continued to evolve since then, so some capabilities or limitations described below may have changed.

## What is SuperPlane?

[SuperPlane](https://superplane.com/) is an open source tool, still in beta, that sits in the middle. On one side, you have the tools you already use, like [Git](https://git-scm.com/), your CI, your cloud, and your monitoring. On the other, you have your actual infrastructure. SuperPlane sits between them.

The way it works is that you build a small graph of steps. Something like “deploy this,” then “wait for someone to approve,” then “check a metric,” then “send a message.” SuperPlane runs that graph for you, and it keeps running even if something restarts in the middle. You can also drop a human step anywhere you want, so nothing happens without approval unless you allow it.

![See the workflow, Control it like code](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/See_the_workflow_Control_it_like_code_031b5d8610.png)
_See the workflow, Control it like code_

The part we liked from the start is that each app is just files in Git. There is a `canvas.yaml` for the workflow and a `console.yaml` for the dashboard. So you can read it, review it, and keep versions of it like any normal code. You are not clicking around in some interface that nobody can track later.

The reason we care about this kind of tool at all is simple. In most teams, the “glue” between people and infrastructure is a mess of small scripts and things that only one person really understands. SuperPlane turns that glue into **something you can see, control, and improve** as a team.

## How We Tested SuperPlane: Two Real Workflows

Here is the thing, though: one workflow doesn't tell you much. If you only build the happy path, of course it works. You only find the real problems when you push a tool in both directions.

So we built two workflows, and we made them go opposite ways. Both of them talk to [DigitalOcean](https://www.digitalocean.com/), because that is the cloud we had a token for. One workflow sends commands out to the infrastructure. The other one reacts to something happening in the infrastructure. That is the full loop, and building both of them is where we actually learned something.

### Workflow 1: A Guarded DigitalOcean Deployment Pipeline

The first one is a deployment with some rules around it. A person clicks a button to start it. Before anything reaches [DigitalOcean](https://www.digitalocean.com/), [SuperPlane](https://superplane.com/) checks a few things:

- Is this the main branch? If not, stop.
- Is it during work hours, Monday to Friday, 9 to 5? If not, hold it.
- Did a human approve it? If not, wait.

Only after all three conditions are met does it actually redeploy the app on [DigitalOcean](https://www.digitalocean.com/), record that the deployment happened, and show it on a small dashboard.

The nice part is that each of those checks is just a small block in the file. Here is the “only during work hours” step, for example:

```yaml
- name: "Business hours only"
  component: "timeGate"
  configuration:
    days: ["monday", "tuesday", "wednesday", "thursday", "friday"]
    timeRange: "09:00-17:00" 
```
And the approval step is even shorter. This one just says, “Somebody has to approve before we continue”:

```yaml
- name: "Release approval"
  component: "approval"
  configuration:
    items:
      - type: "anyone"
```

This is not flashy, but it solves exactly the kind of operational problem that most teams get wrong: which branch you allow, when deployments are allowed, who has to approve, and how you keep a record of what happened. Normally, this lives in someone's head or in a script full of if-statements. Here, it was just a few blocks connected together, and we could see the whole thing at a glance.

![unnamed (4).png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/unnamed_4_685d7da047.png)

###Workflow 2: Auto-Rebooting a Droplet on a CPU Spike
The second one is the opposite direction. Every few minutes, [SuperPlane](https://superplane.com/) looks at a server's CPU. If it goes over 80 percent, it shows an alert, asks a person to approve a reboot, reboots the server, and writes down what happened.

The check itself is basically one line. This block reads the metric from the previous step and checks whether the average CPU usage is above 80 percent:

```yaml
- name: "CPU above 80%?"
  component: "if"
  configuration:
    expression: '$["Read droplet metrics"].data.avgCpuUsagePercent > 80'
```

Then you connect the “yes” and “no” paths. In SuperPlane, the lines between steps carry a channel, so a check like this has a true side and a false side:

```yaml
edges:
  - sourceId: "CPU above 80%?"
    targetId: "High CPU detected"
    channel: "true"
  - sourceId: "CPU above 80%?"
    targetId: "Droplet healthy"
    channel: "false"
```

So the “true” path goes to the alert and reboot, while the “false” path marks the server as healthy and stops.

This is the “notice something and do something about it” pattern: the reactive half of running infrastructure and often the more challenging half to build well. Testing this workflow also showed us where[ SuperPlane](https://superplane.com/)’s event support could be expanded.

## What We Liked About SuperPlane
The rules, or guardrails, are easy to add: “only from main,” “only during work hours,” and “wait for approval.” These are not things we had to code. They are just blocks you drop into the flow, and each block has a clear yes path and no path.

If your problem is people deploying whenever and however they feel like, this part alone is worth it.

You get storage and a dashboard almost for free. Each app can keep its own data, and the dashboard reads straight from that. We made a table of incidents and a “highest CPU we've seen” number without setting up a database or building a frontend. That saved us real time.

Everything is files plus an API. It is all canvas.yaml and console.yaml, with a normal draft, commit, and publish flow, like Git. We wrote the files and pushed them through [SuperPlane's API](https://docs.superplane.com/concepts/api-reference/).

The interface, the files, and the API are just three views of the same thing. If you like doing things as code, you will feel at home here.

## SuperPlane Integrations and Advanced Features
We only built two workflows, but while we were in there, we looked at the rest of it, and there is a lot more that [SuperPlane](https://superplane.com/) can do. A few things stood out.

![SuperPlane Integrations and Advanced Features](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Super_Plane_Integrations_and_Advanced_Features_d6b21d8138.png)
_Connect the tools you wanted to have & control the flow._

First, it connects to far more than clouds. There are around 47 integrations, and they cover much of the tooling a team already uses: CI tools like GitHub and GitLab; incident and on-call tools like [PagerDuty](https://www.pagerduty.com/) and [Rootly](https://rootly.com/); chat tools like Slack, Discord, and Teams; and monitoring tools like [Datadog](https://www.datadoghq.com/), [Grafana](https://grafana.com/), Prometheus, and Sentry. So a workflow does not have to stay inside one tool. A realistic one might start when an incident is opened, pull the last few deployments and some health numbers, post a summary to Slack, and open a ticket, all in one graph.

Second, there are more building blocks. You can loop over a list and run the same step for each item, and you can wait for several things to finish before moving on. That "wait for all of them" piece is how you would build something like a release that only continues once three different services are ready.

Third, there is an escape hatch for anything that does not have its own integration. There are plain HTTP and GraphQL steps, and an SSH step that runs a command on a server. It is not native, but you can reach the [Kubernetes](https://www.cyberlab.rs/blog/kubernetes-development-skaffold) API over HTTP or run `kubectl` over SSH, like this:

```yaml
- name: "Restart the deployment"
  component: "http"
  configuration:
    method: "POST"
    url: "https://my-cluster.example.com/apis/apps/v1/namespaces/prod/deployments/api"
```
It is not as clean as a native integration, but it is a practical escape hatch that means you are rarely completely stuck.

Fourth, it can call AI models in the middle of a workflow. There are blocks for [Claude](https://claude.ai/) and [OpenAI](https://openai.com/), so you could have a step summarize an incident or draft a message, and then put a human approval right after it so nothing goes out without someone reading it first. There is also a built-in assistant that helps you build and debug the workflows themselves, and the same permission rules apply whether a person or an AI agent is the one doing something.

## Is SuperPlane Right for You? Requirements and Limitations
You do not have to be a developer to use SuperPlane, but you do need to understand the infrastructure you are connecting to it. You need to know about tokens and APIs, and what an app or a server actually is. You also need to understand the difference between an event, which is something being pushed to you, and polling, which is you asking again and again. That difference decides a lot about what you can and cannot build. And you should be fine with basic YAML and with thinking in terms of flows and graphs. Someone with no technical background would really struggle to set this up on their own.

## Final Thoughts: Is SuperPlane Worth Trying?
[SuperPlane](https://superplane.com/) solves a real problem. It takes the messy glue between your team and your infrastructure and turns it into workflows you can see, govern, and keep in version control. The guardrails, built-in storage and dashboards, and files-plus-API approach make it much easier to turn operational knowledge into a system the whole team can understand and use. We enjoyed working with it.

We think it gives teams a structured way to replace scattered scripts and manual coordination with visible, governed workflows. It is still a beta product with room to grow, but the foundation is already useful, and the open source version makes it possible to test that value against your own infrastructure.

If any of this sounds like a problem you are dealing with, that is the kind of thing we help teams work through at [CYBERLAB](https://www.cyberlab.rs/). Our advice is: do not trust our write-up, and do not trust anyone's demo either. Take the open source version, connect it to something real, and push it in both directions as we did. You will learn more in one afternoon of building than in a week of reading. And if you want a hand while you test it, just reach out.




We Tested This DevOps Orchestration Tool Both Ways

A hands-on guide to ECS Managed Daemons, AWS's answer to Kubernetes DaemonSets, with step-by-step setup for running agents like CloudWatch on ECS.

ECS Managed Daemons:

Every DevOps engineer who is working with ECS and managing monitoring for services knows how hard it can be. You have more than 30 services. A new version of the CloudWatch Agent is released. To update services, you're coordinating with five application teams, creating 30 new task definition revisions, and triggering 30 rolling deployments - just to bump an agent version. One mistake and you have a gap in your monitoring. \
 \
[Kubernetes](https://kubernetes.io/ ) had a clean answer to this problem for years: the DaemonSet. One resource, one agent per node, managed independently of applications. Now, ECS is catching up, also. \
 \
[AWS announced ECS Managed Daemons in April this year](https://aws.amazon.com/blogs/aws/announcing-managed-daemon-support-for-amazon-ecs-managed-instances/). This is a native construct that decouples operational agents from application task definitions. In this post, I'll walk you through what it is, how it works, and how to set it up using the AWS Console.

**In short:** 

ECS Managed Daemons are a native AWS construct that decouples operational agents - like the CloudWatch Agent - from your application task definitions, much like a Kubernetes DaemonSet. 

Instead of bundling a monitoring sidecar into every service and redeploying dozens of services just to bump an agent version, you define the daemon once at the cluster level and ECS guarantees exactly one agent per instance - started before your apps and drained last, so monitoring never has a gap. 

Platform teams can update agents independently of application teams, with automatic start-before-stop rollouts and circuit-breaker rollback. The one catch: Managed Daemons work only with ECS Managed Instances capacity providers - not the classic EC2 launch type or Fargate. 

This post covers what they are, how they work, and how to set one up from the AWS Console.

## The Problem with the Sidecar Pattern

Before Managed Daemons, the standard way to run a monitoring agent for your application on [ECS](https://aws.amazon.com/ecs/) was the sidecar pattern: add an agent container directly inside your task definition. This is a problem for more than one reason:

* **Tight coupling:** If I want to update a new version of the monitoring agent, I need to update the task definition, which will create a new revision, and I need to redeploy the whole service, which includes the application container
* **Resource waste:** Every task runs a side container for monitoring. If you have 30 tasks, you will have 30 monitoring containers running.
* **Inconsistency risk:** Teams can accidentally omit the sidecar, leaving some services unmonitored without anyone noticing.

## What Are ECS Managed Daemons?

ECS Managed Daemons are a dedicated service for operational agents that is completely separate from your application task definitions. You define it once at the cluster level, and you are assured that it will execute for every service.

Key benefits:

* **One daemon per instance:** ECS creates exactly one daemon task per managed instance
* **Start before applications:** The daemon is guaranteed to be running before any application task is placed on that instance.
* **Drain last:** When an instance is being replaced or drained, the daemon is the last thing to stop, ensuring no gap in observability coverage.
* **Independent lifecycle:** Platform teams can update the daemon without touching application task definitions or coordinating with application teams.

One thing to keep in mind before you get excited: Managed Daemons only work with ECS Managed Instances capacity providers. Classic EC2 launch type and Fargate are not supported. 
 
## Step-by-Step: Setting Up a Managed Daemon via the Console

Before getting started, we need to create:

* An ECS cluster with a Managed Instances capacity provider configured
* An IAM task execution role
* The container image you want to run as a daemon (we'll use the CloudWatch Agent) 
* Created log group /ecs/cloudwatch-agent-daemon

### Step 1: Create a Daemon Task Definition

![slika 1png.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_1png_9590d0fe26.png)

Configure the following:

* **Daemon task definition family:** Give it a name, like cloudwatch-agent-daemon
* **Task execution role:** Select ecsTaskExecutionRole
* **Create a CloudWatch Agent Task Role:** Create a new IAM Task role, with name **CloudWatchAgentTaskRole,** and attach** CloudWatchAgentServerPolicy** AWS managed policy
* **CPU:** 1 vCPU
* **Memory:** 512 MB

Under Container, add your agent container:

* **Name:** cloudwatch-agent
* **Image URI:** public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest
* Set configuration for CW Agent; create one env variable:


```
key: CW_CONFIG_CONTENT
value: {\"metrics\":{\"metrics_collected\":{\"cpu\":{\"measurement\":[\"cpu_usage_idle\"],\"metrics_collection_interval\":60}}},\"logs\":{\"metrics_collected\":{\"emf\":{}}}}
```
![slika 2.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_2_bc9df2d3f8.png)

### Step 2: Create the Daemon on Your Cluster

Go to Clusters tab → Select your cluster → Open Daemons tab
![slika 3.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_3_5fed36817f.png)

Click Create daemon and configure:
* **Daemon name:** e.g., monitoring-agent
* **Daemon task definition:** Select the family you just created
* **Capacity provider:** Select your Managed Instances capacity provider
* **Drain percentage:** Controls the pace of rolling replacements during updates (50% means at most half your instances can be in the drain state simultaneously)

![Slika 4.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Slika_4_ae8141d024.png)

### Step 3: Verify the Daemon is Running

Create a testing service which will be monitored (e.g., nginx, hello world).

You'll observe that the daemon was already running before the application task was placed - no manual intervention required.
![Slika 5.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Slika_5_32c06917b4.png)

Before the nginx service deployment, there was no instance of the cloudwatch-agent daemon, but when the deployment of the service started, the cloudwatch agent deployed one task first, and then the deployment of the service continued.

## How Updates Work

In this part, I will explain the main advantage of daemons over the sidecar pattern. When you need to update the agent to a new version, ECS handles the rollout automatically using a "start before stop" strategy.

The old daemon on the outgoing instance stays alive until all application tasks have successfully migrated to a new instance running the updated daemon. Service will have one available agent in every moment, there is no gap in monitoring or logs shipping.

ECS also includes automatic rollback via circuit breaker. If the new daemon fails health checks during a rollout, ECS stops the replacement and rolls back, protecting your services.

## When to Use Managed Daemons?

Managed Daemons are a great fit for any agent that needs to run on every instance, independently of which applications are deployed. 

When NOT to use Managed Daemons:

* Application-specific sidecars that only make sense alongside a specific service
* Init containers or one-time setup tasks

## Conclusion

My recommendation is to use Managed Daemons every time there is a need for a sidecar agent. One of the biggest wins for me is that I can work separately on updating or creating agents without clashing with developers' work and progress. And there's another thing worth mentioning - no more gaps in monitoring.

The only problem I have currently is that on some projects, we are not using managed instances for ECS, and there are no plans in the future for using them, so we are limited to going the old way. 

If you're currently running monitoring agents as sidecars on ECS Managed Instances, this feature is worth evaluating immediately. The migration path is straightforward - extract the agent container from your task definitions, create a daemon task definition, and let ECS manage the rest.

Found this useful? [Check out our other blog posts for more insights on cloud architecture](https://www.cyberlab.rs/blog ).

## Resources
* [AWS Blog: Announcing managed daemon support for Amazon ECS Managed Instances](https://aws.amazon.com/blogs/aws/announcing-managed-daemon-support-for-amazon-ecs-managed-instances/)
* [Amazon ECS Managed Daemons Documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-daemons.html)
* [Amazon ECS Managed Instances product page](https://aws.amazon.com/ecs/managed-instances/)
* [CloudWatch Agent on ECR Public Gallery](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent)

The DaemonSet Equivalent ECS Was Always Missing

For the third year in a row, CYBERLAB joined the KTJ Club Business Challenge running 1,237 km to support a child in need of ongoing medical treatment.

Running for Neda: 

For the **third year in a row,** the [CYBERLAB](https://www.cyberlab.rs/meet-the-team) team joined the [KTJ Club](https://www.linkedin.com/company/ktj-club/posts/?feedView=all) Business Challenge. A month-long initiative where companies across Serbia convert their employees' kilometers into donations for children in need. This May, our team ran **1,237 kilometers** and raised **100.000 RSD** to support the ongoing medical treatment of a little girl named [Neda Ranđelović](https://pokrenizivot.com/cir/korisnik/neda-randjelovic-239). Here's what that month actually looked like from the inside.
## Our Why - Neda Ranđelović 
Neda was born after a healthy, regularly monitored pregnancy. However, complications during delivery later resulted in a diagnosis of cerebral palsy.

When we heard about Neda’s story, we were deeply moved by her strength and the dedication of her family. During the first year of the challenge, we decided to direct our fundraising efforts toward helping Neda. By the end of that month, we had built a genuine connection with her and her family, who, in turn, supported and cheered us on throughout the entire challenge. Seeing how much the treatment had helped her progress made us proud to have played even a small part in her recovery.

Earlier this year, when we heard that Neda needed a new cycle of therapy, the answer was simple: we wanted to help again.

![2.jpg](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/2_7572d98eff.jpg)
## About the KTJ Club Business Challenge
The **KTJ Club Business Challenge** founded in April 2024, a simple idea by KTJ Club: turn everyday kilometers into meaningful support for children in need. From the start, six companies joined the initiative, and **CYBERLAB was among them**. Back then, 190 colleagues took part. This year, that number grew to 26 companies with more than 1,000 participants.

The concept was designed from the ground up for everyday runners, not just seasoned athletes. Teams of up to 25 colleagues form a running squad; companies could register more than one, and convert their kilometers into donations for a child or children's institution of their choice. Every kilometer counts, every step carries a meaning beyond the finish line.
## How a Shared Purpose Brought Our Team Closer
On paper, the challenge was simple: run, log kilometers on Strava, repeat. In practice, it quietly rewires how a team operates for an entire month.
For those joining the challenge for the first time, the motivation came naturally from the team itself. There was always someone in the group chat sending an invite for a run, and **when you run with others, you inevitably push past what you thought you could do**. A kilometer or two more than planned, a limit quietly crossed. 

**The company played its part too** by providing our runners with proteins and healthy food throughout May, giving the whole initiative an extra push.

And then there was **Bojan Čakar**, **our colleague and unofficial captain, who kept the team's energy up throughout the month with protein pancakes and shakes**. By the end of May, that same energy carried a part of the team all the way to Fruška Trail, 15 kilometers through Fruška Gora, a serious challenge by any standard, and proof that what started as a charity run had become something the team genuinely wanted to push further.

Without overthinking it, that's how 1,237 kilometers happened logged across two countries, with teammates running in Novi Sad, Belgrade, Bijeljina, and Banja Luka.
![KTJ Kraj izazova 2026 (1).jpg](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/KTJ_Kraj_izazova_2026_1_bcc68383e4.jpg)
## More than a finish line
By the end of May, we were all in better shape than when we started, and not just physically. We pushed past our own limits, ran through rain without thinking twice, and finished the challenge as a tighter, closer team.

As individuals, we grew. As a collective, we bonded. And as part of a wider community, we made a contribution that we hope made a difference.
When it comes to helping others, no gesture is too small. Every kilometer, every donation, every share matters. If you'd like to add your voice to this story and support Neda's ongoing treatment, you can do so right now by sending an SMS with the text **239** to **3800**.

As for us,  we had a great time, and this is far from the only initiative we're part of. If you'd like a peek into our team culture and what we're up to, we'd love to have you follow along. Stay connected with us on [LinkedIn](https://www.linkedin.com/company/69988472/admin/notifications/all/), [Instagram](https://www.instagram.com/wearecyberlab/), and [Facebook](https://www.facebook.com/cyberlabsolutions/).




The Story Behind CYBERLAB's 1,237km

The “Claude Code 101” event in Novi Sad showcased practical AI-assisted development with Claude Code, led by Uroš Petrić from CYBERLAB.

How AI Is Changing the Way We Write Code:

On Tuesday, **April 21st, 2026,** we hosted an event at [Prostor](https://www.facebook.com/prostorgradic/?locale=sr_RS) in Novi Sad titled **“Claude Code 101: From Zero to Full Potential.”** Interest in the event was exceptionally high, with 100 attendees joining us, including software engineers, frontend and backend developers, students, and IT enthusiasts.

The venue was at full capacity, reflecting how quickly AI-assisted development tools have evolved from a curiosity into an essential part of everyday work in modern software teams.

## Speaker: Uroš Petrić - Software Engineer with Hands-On AI Development Experience

The session was delivered by our colleague [Uroš Petrić](https://www.linkedin.com/in/urospetric/), [Software Engineer](https://www.cyberlab.rs/meet-the-team) at [CYBERLAB](https://www.cyberlab.rs/), who brings extensive experience in application development and the practical use of AI tools in everyday engineering work. Within [CYBERLAB](https://www.cyberlab.rs/), Uroš successfully led the development of an internal application from idea to production in just a few weeks, with AI assistance playing a key role throughout the entire process. He regularly shares his knowledge and experience with colleagues through internal knowledge-sharing sessions.

![Software Engineer at CYBERLAB Leading hands-on AI-assisted development with Claude Code](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/1_2_3ca0a3f73f.png)

In this session, he demonstrated what a real-world AI-assisted development workflow looks like in practice, and how tools like [Claude Code](https://claude.ai/) can become a natural extension of a developer’s daily toolkit.

## What Does AI-Assisted Development Look Like in Practice?

Uroš walked participants through the complete picture of working with [Claude Code](https://claude.ai/), from understanding what a coding assistant actually is, to configuring advanced automation, parallel agents, and external integrations. The presentation covered the following core topics:

#### 1. Coding Assistant - Beyond the Chat Interface

The audience learned how [Claude Code](https://claude.ai/) differs from a simple chat interface and how it bridges the developer and the language model through a structured tool layer. **A key insight:** the language model does not execute actions itself; it requests the coding assistant to perform them, which means the developer retains full control over what happens in their codebase.

#### 2. Tools - What Claude Code Can Do

Uroš walked through the full set of built-in tools available to [Claude Code](https://claude.ai/), including Bash, Edit, Glob, Grep, Read, Write, WebFetch, WebSearch, and the Agent tool for launching subagents. Participants gained an understanding of how Claude decides which tool to use and how additional capabilities can be added through MCP server integrations.

#### 3. Context - Giving Claude What It Needs

One of the most practical segments of the talk focused on context management. Providing the right information and avoiding irrelevant or misleading context directly determines the quality of Claude's output. Uroš explained how context windows work, why they fill up, and how to manage them effectively during long sessions.

![PROSTOR I Novi Sad I CYBERLAB](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Uros_Petric_Claude_Code_101_From_Zero_to_Full_Potential_e4b707dfb4.jpg)
#### 4. CLAUDE.md and Auto Memory

The session covered CLAUDE.md, the single most impactful configuration file in any [Claude Code](https://claude.ai/) project. Loaded automatically at the start of every session, it acts as Claude's persistent memory,  documenting the tech stack, architecture, build commands, workflows, and project-specific gotchas. Alongside CLAUDE.md, Uroš introduced Auto Memory, which accumulates knowledge across sessions without any manual effort, storing learnings in plain markdown files that Claude reviews at the start of each new conversation.

#### 5. Planning and Thinking Modes

Participants learned how to shift [Claude Code](https://claude.ai/) into different operational modes depending on the task at hand. Plan Mode restricts Claude to read-only tools, allowing it to thoroughly explore the codebase and produce a detailed implementation plan before touching a single file. Thinking modes, from basic Think to Ultrathink, give Claude progressively more reasoning capacity for complex logic problems, difficult debugging scenarios, and algorithmic challenges. Uroš also clarified an important distinction that often causes confusion: effort and thinking are separate controls, and increasing one does not automatically increase the other.

#### 6. Commands

The talk explained how commands extend Claude Code's functionality through simple slash notation. Participants saw examples of both built-in commands, such as /compact, /clear, /memory, and /agents, as well as custom commands stored in the .claude/commands directory. The $ARGUMENTS pattern for parameterized commands proved particularly popular among attendees.

#### 7. Skills

Skills are markdown guides that Claude auto-invokes based on the context of a conversation. Unlike commands, which require manual triggering, skills activate automatically when Claude recognizes a relevant situation. Uroš demonstrated how a well-written description field in a SKILL.md file is the key to reliable auto-activation, and walked through several practical skill ideas including code-review, testing-patterns, explain-code, and docker-deploy.

![CYBERLAB](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Uros_Petric_7e15908ce3.jpg)

#### 8. Agents and Subagents

The second half of the session was dedicated to subagents, which drew considerable attention from the audience. Subagents are specialized AI assistants that handle specific tasks in fully isolated contexts, each running with its own system prompt, tool access, and independent permissions. Through concrete examples, Uroš demonstrated how subagents help preserve the main conversation context, enforce constraints on tool usage, enable parallel task execution, and even control costs by routing lighter tasks to faster, cheaper models. He also walked through the three built-in subagent types, Explore, Plan, and General Purpose, each with different model and tool configurations suited to different stages of a workflow.

#### 9. MCP Servers

Model Context Protocol servers unlock integrations with external services directly from Claude Code. The talk covered a range of practical integrations, including GitHub for repository and pull request management, Figma for design-to-code workflows, Notion for workspace connectivity, Slack for messaging and data retrieval, and Playwright for automated browser testing. Participants left with a clear picture of how MCP transforms Claude Code from a standalone coding assistant into a connected development hub.

#### 10. Hooks

The final topic covered Hooks, one of the most powerful and underused features in Claude Code. Hooks allow developers to run a command before or after Claude Code performs any action, and optionally block that action entirely. Use cases demonstrated during the session included automatically running a code formatter after every file edit, blocking commits that introduce deprecated function calls, checking for TODO comments and logging them to a file, and enforcing naming conventions across the codebase. Participants saw how PreToolUse hooks can serve as safety gates and can block an action by returning exit code 2, while PostToolUse hooks provide a way to react to Claude's actions without interrupting the flow.

![Q and A](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/NEM_187_resized_7efcc9e449.jpg)

## Learning Resources

At the end of the presentation, attendees received a curated list of resources for further exploration:

* [Claude Code in Action course](anthropic.skilljar.com/claude-code-in-action) 
* [Claude Code official documentation](docs.anthropic.com/claude-code) 
* [Claude Code Templates](https://www.aitmpl.com/)
* [Claude Code Best Practices](https://github.com/shanraisshan/claude-code-best-practice)
* [CYBERLAB blog](www.cyberlab.rs/blog) 

These materials provide an excellent starting point for anyone looking to integrate Claude Code into their daily development workflow.

## Networking 

After the presentation, participants enjoyed an informal networking session, where they had the opportunity to talk with Uroš and the [CYBERLAB](https://www.cyberlab.rs/) team about their projects, questions, and early experiences with Claude Code. Topics ranged from practical CLAUDE.md setups and skill configurations to broader questions about where AI-assisted development is heading and how teams can adopt it gradually without disrupting existing workflows.
![Networking I CYBERLAB](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Uros_Petric_I_Claude_Code_81335a7dde.jpg)

## Conclusion

The **"Claude Code 101: From Zero to Full Potential"** event demonstrated that the local developer community is actively exploring AI tools and looking for concrete, practical guidance on how to use them well. AI-assisted development, intelligent context management, and autonomous coding agents are becoming increasingly relevant across all types of software projects, and this meetup once again highlighted how shared learning strengthens the entire community.

See you at the next [CYBERLAB](https://www.cyberlab.rs/) event!

We're always happy to share our knowledge and experiences. Feel free to follow or reach out to us on [LinkedIn](https://www.linkedin.com/company/cyberlabsolutions) |[ Facebook](https://www.facebook.com/cyberlabsolutions/) |[ Instagram](https://www.instagram.com/cyberlabsolutions/). 


Insights from a Community Talk on Claude Code and AI-Assisted Development

Pozivamo vas da nam se pridružite na događaju koji organizujemo na temu “Claude Code 101: From Zero to Full Potential", 21. 4. sa početkom od 18h u Prostoru, u Novom Sadu.

Claude Code 101:

Pozivamo vas da nam se pridružite na događaju koji organizujemo na temu **“Claude Code 101: From Zero to Full Potential"**, **21. 4.** sa početkom od **18h** u [Prostoru](https://www.facebook.com/prostorgradic/?locale=sr_RS), u Novom Sadu.

Evo svega što trebate da znate:

## Ko je predavač?

U ulozi predavača naći će se [Uroš Petrić](https://www.linkedin.com/in/urospetric?skipRedirect=true&miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAACIr7FIBfVR4sK3Q_p4JwLgaqomQg9uoimg), softver inženjer sa višegodišnjim iskustvom u razvoju aplikacija i aktivnoj primeni AI alata u svakodnevnom radu. U okviru [CYBERLAB](https://www.cyberlab.rs/)-a Uroš je, uz pomoć AI, uspešno vodio razvoj interne aplikacije od ideje do produkcije za svega nekoliko nedelja. Svoje znanje i iskustvo Uroš redovno deli sa kolegama kroz interne knowledge sharing sesije.

Na predavanju vas očekuju jasni uvidi u to kako AI alati mogu da unaprede svakodnevni razvojni proces, bez obzira na tehnologiju koju koristite.

## O čemu će biti reči?

Ovom prilikom, Uroš će govoriti o tome:

* Šta je Claude Code i kako funkcioniše kao coding assistant
* Ključnim konceptima: Tools, Context, CLAUDE.md, Memory, Commands, Skills, Agents, MCP Servers i Hooks
* Kako efikasno kontrolisati razgovor i maksimalno iskoristiti Claude Code u svakodnevnom radu

## Kome je predavanje namenjeno?

* Developerima i softver inženjerima koji žele da ubrzaju svoj workflow
* IT profesionalcima koji žele da razumeju kako AI menja način na koji se piše kod
* Svima koji su radoznali, predavanje kreće od osnova i pokriva sve najbitnije celine

## Zašto da se prijavite?

Ova tema može biti posebno zanimljiva ukoliko:

* Još niste počeli da koristite coding assistente, ali razmatrate tu mogućnost
* Koristite AI alate u svom radu, ali niste sigurni da li ih koristite na optimalan način
* Tražite konkretne tehnike i prakse koje možete odmah primeniti u svom projektu

Pozivamo vas da nam se pridružite i steknete vredne uvide koji će vam pomoći da izvučete maksimum iz Claude Code-a u svakodnevnom radu.

## Kako da se prijavite?

Broj mesta je ograničen, stoga je neophodno da potvrdite svoje prisustvo popunjavanjem forme koja se nalazi u nastavku. Prijave su otvorene **ponedeljka, 20. aprila do 12h** a u slučaju popunjavanja svih mesta, prijave će biti zatvorene i ranije.

## **[PRIJAVITE SE OVDE 👈](https://forms.gle/c4wgUrTq9PfYx1xe8)**

Nakon predavanja vas očekuje networking i neformalno druženje tokom kojeg ćete imati priliku da sa Urošem diskutujete o različitim temama i postavite sva pitanja koja vas zanimaju o korišćenju Claude Code-a i AI alata u svakodnevnom radu. Vidimo se u **utorak, 21. aprila u 18h** u [PROSTOR](https://share.google/om60XImwwLZ5tjHkE)-u! 🙂


From Zero to Full Potential

CYBERLAB is now an AWS Select Tier Services Partner, recognized for technical expertise, secure and scalable cloud solutions, and proven customer success.

CYBERLAB Achieves:

We’re proud to announce an important milestone for [CYBERLAB](https://www.cyberlab.rs/): **we are now an [AWS Select Tier Services Partner](https://aws.amazon.com/partners/services-tiers/)**. This recognition reflects our technical expertise, strong customer success record, and commitment to delivering secure, scalable, and high-performing cloud solutions.

At a time when organizations face increasing cloud complexity, rising cost pressure, and stricter security demands, this achievement reinforces our role as a **trusted engineering partner** that helps teams move faster with confidence.

## What AWS Select Tier Status Means 

The AWS Select Tier Services Partner designation is awarded to companies that meet strict standards across technical capability, customer success, and operational excellence. For us, it validates that we:

* Design and deliver architectures aligned with AWS best practices for **security, reliability, and performance**
* Successfully support **mission-critical and production workloads** on AWS
* Apply **deep, hands-on expertise** across cloud infrastructure, [DevOps](https://www.cyberlab.rs/devops) automation, and modern application platforms

As a Select Tier Partner, we gain access to enhanced AWS enablement, direct technical guidance, and closer collaboration with AWS experts, allowing us to continuously refine how we design, build, and operate cloud platforms for our partners.

## Tangible Benefits for Our Partners

This milestone translates directly into measurable value for the organizations we work with:

* **Secure and resilient cloud foundations** designed for real production traffic, not just proofs of concept
* **Scalable architectures** that adapt to growth, peak demand, and long-term evolution
* **Faster delivery and innovation**, combining AWS-native services with our DevOps-first approach
* **End-to-end ownership**, from cloud strategy and migration to optimization, automation, and ongoing operations

Whether you’re modernizing legacy systems, migrating to AWS, or optimizing an existing environment, [we](https://www.cyberlab.rs/meet-the-team) help you reduce risk, improve reliability, and shorten time to value.

## What Sets Us Apart

Many organizations hold AWS partner status. What differentiates us is how we deliver and operate:

* **A DevOps-first mindset** focused on automation, observability, and reliability from day one.
* **Extensive experience running complex, production-grade environments**, including high-availability and regulated workloads.
* **Full lifecycle responsibility**: we design, build, operate, and continuously improve cloud platforms.
* **A partner-led delivery model** where we own solution quality and customer experience end-to-end.

AWS provides us with tools and technical support, but we remain fully accountable for results.

## Our Commitment Going Forward

We see this designation not only as a recognition of our past achievements but also as a foundation for **future innovation and collaboration**. It strengthens our ability to help clients navigate cloud adoption, modernization, and optimization, while staying focused on what matters most: **delivering reliable systems and measurable business outcomes**.

If you’re planning a cloud migration, platform modernization, or optimization initiative, we are ready to support you with proven expertise and hands-on delivery.

Discover how [CYBERLAB](https://www.cyberlab.rs/), together with [Amazon Web Services](https://aws.amazon.com/), can help your business build, scale, and operate with confidence in the cloud. [Contact us](https://www.cyberlab.rs/contact) today to get started.


AWS Select Tier Services Partner Status

Over 150 participants came together at our New Year’s Charity Pub Quiz in Novi Sad, raising 1,400 EUR to support Minja, Strahinja, and Vukašin in their fight against a rare ADSL gene mutation.

New Year’s Charity Pub Quiz:

On **December 23, 2025,** we held our[ New Year’s Charity Pub Quiz](https://www.cyberlab.rs/blog/cyberlab-novogodisnji-humanitarni-pub-kviz-minja-strahinja-vukasin) at The Pub in Novi Sad, bringing together colleagues, friends, and members of the local community for an evening dedicated to knowledge, teamwork, and giving back.

Thanks to the generosity of all participants, **we raised and donated 1,400 EUR** to support **Minja, Strahinja, and Vukašin** in their fight against a rare ADSL gene mutation and to help fund the treatment they needed.
![New Year’s Charity Pub Quiz: Supporting Minja, Strahinja, and Vukašin](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_7e762b2e07.jpg)

## A Tradition Built by People and Ideas

The story of our quiz began a few years ago as an internal [CYBERLAB ](https://www.cyberlab.rs/)initiative, launched by **Dragan Perić** and **Andrija Vojnović**. What started as a small team event gradually grew into a tradition that brings people together beyond the company walls.

Last year, this tradition took an important step forward with the [DragiAndro Quiz Special](https://www.cyberlab.rs/blog/dragiandro-quiz-for-childrens-smile), the first open charity edition of the quiz, which marked the transition from an internal gathering to a community-focused event with a humanitarian goal.

Building on that momentum, the concept continued to evolve through the efforts of **Nemanja Radoičić** and **Bojan Baškalo**, who brought new energy to the format through the **BN Quiz** and helped further strengthen the quiz culture within the team. This year, for the first time, these initiatives came together in a joint charity event with an even greater impact.

![New Year’s Charity Pub Quiz: Supporting Minja, Strahinja, and Vukašin - Hosts](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_Bojan_Baskalo_Andrija_Vojnovic_Nemanja_Radoicic_a65d9aa698.jpg)

## Turning Knowledge into Support

A great atmosphere, friendly competition, and a shared sense of purpose marked the quiz night. With a symbolic ticket price and strong community participation, the event showed how small individual contributions can turn into meaningful collective support.

Raising **1,400 EUR** in a single evening is a clear example of what can be achieved when people come together around a common goal.

![Participants in a quiz ](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_61511c83dd.jpg)

## Thank You for Making It Possible

We would like to thank [Elite Tennis Academy](https://tennisacademyelite.com/), [Bossi Pizza](https://www.facebook.com/p/Bossi-Pizza-100052412786270/), and [Arena Cinaplex](http://www.arenacineplex.com/) for supporting the quiz and providing prizes. A special thank-you goes to [Andrija, Nemanja, and Bojan](https://www.cyberlab.rs/meet-the-team), whose dedication and enthusiasm helped turn an idea into a successful charity event.

Most of all, thank you to everyone who participated and contributed.

![Quiz Question](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_67e0572ae0.jpg)

## United for a Common Goal

This quiz once again showed how much can be achieved through collaboration and shared effort. By combining knowledge, teamwork, and community support, we created an event with a real and measurable impact

Although the quiz night is over, the initiative continues. We invite everyone who would like to contribute further to support Minja, Strahinja, and Vukašin by following the donation instructions **[here](https://www.budihuman.rs/korisnik/1417/minja-lapcevic)**. 

Stay connected with us on [LinkedIn](https://www.linkedin.com/company/69988472/admin/notifications/all/), [Instagram](https://www.instagram.com/wearecyberlab/), and [Facebook](https://www.facebook.com/cyberlabsolutions/) to keep up with future initiatives.


 Supporting Minja, Strahinja, and Vukašin

Setting up a local Kubernetes cluster using Kind, deploying a demo app, and seeing how Skaffold streamlines the process for faster development and testing.

Kubernetes Development:

As more organizations shift towards cloud native software approach, whether it be tight or loosely coupled technique, the challenging part is to provide developers with development environments that can support a smooth transition. \
On the cloud native palette there are a couple of tools that can provide this loop for developers with one topic in focus - “write code”.


## What is Skaffold?

[Skaffold](https://skaffold.dev/) is an open-source project released by Google with some key areas that covers:



* It is lightweight client-side only tool, that developers can easily install on local machine 
* It must works everywhere, meaning easy share project with other developers
* If covers all container and[ kubernetes]( https://kubernetes.io/) features that makes developers productive more
* It must provide continuous feedback to developers while developing

Now that I get your attention, shall we dive a little further?


## Prerequisites

In order to follow my presentation, I’ve prepared code available for you at [skaffold-demo](https://github.com/Igor992/skaffold-demo ) 


There is **Makefile**, just in case that you’re wish to follow along with the reading this blog

```
➜ skaffold-demo git:(main) ✗ make
Usage:
  make [ COMMAND ]

Commands:
  all        Run all targets
  tools      Install necessary tools
  cluster    Install local cluster
  ingress    Setup ingress-nginx controller
  skaffold   Generate voting-app images
  certs      Make locally trusted development certificates
  hosts      Add hosts to /etc/hosts

```

When we finish this setup you can use **make all** to get all-at-once prepared, but for now let’s start step-by-step. \
By that said, use **make tools** and you will be prepared on tools that we will need on local machine \
**in my case this is already up-to-date*


```
➜ skaffold-demo git:(main) ✗ make tools

🍺 Install necessary tools
brew install --quiet homebrew/core/kind
brew install --quiet homebrew/core/kubernetes-cli
brew install --quiet homebrew/core/helm
brew install --quiet homebrew/core/skaffold
brew install --quiet homebrew/core/mkcert
brew install --quiet homebrew/core/nss

```



### Setup local cluster

We will use Kind as a local cluster that operates over Docker installed on your machine. 

I will assume that you know what Docker is and that it is already installed on your machine. \
As a good practice I always run the below command to keep the machine clean.

**docker system prune --all --force --volumes**

Now run **make cluster** and wait couple of minutes (time for coffee)


```
➜ skaffold-demo git:(main) ✗ make cluster

🚀 Install local cluster
kind create cluster --config /Users/igor/Documents/CyberLab/skaffold-demo/k8s/kind.yaml --wait 5m
Creating cluster "develop" ...
 ✓ Ensuring node image (kindest/node:v1.32.2) 🧊
 ✓ Preparing nodes 🧱
 ✓ Writing configuration 📝
 ✓ Starting control-plane 🧑‍✈️
 ✓ Installing CNI 🌐
 ✓ Installing StorageClass 💾
 ✓ Joining worker nodes 🧩
 ✓ Waiting ≤5m0s for control-plane = Ready 🏁
 ✓ Ready after 1s 🎉

Set kubectl context to "kind-develop"

You can now use your cluster with:

kubectl cluster-info --context kind-develop

Have a nice day! 👋
```

At this point you should get pointed to kind context locally as 

```
➜ skaffold-demo git:(main) ✗ kubectl config current-context
kind-develop

➜ skaffold-demo git:(main) ✗ kubectl cluster-info
Kubernetes control plane is running at https://127.0.0.1:54784
CoreDNS is running at https://127.0.0.1:54784/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
```




### Setup ingress controller

You can skip this if you want, but I prefer to set up ingress and prepare later locally trusted development certificates. 
If want to follow use **make ingress** and wait until we met the condition meaning that’s all good and running to be used inside this local cluster.


```
➜ skaffold-demo git:(main) ✗ make ingress

🧩 Setup ingress-nginx controller
kubectl apply --filename /Users/igor/Documents/CyberLab/skaffold-demo/k8s/ingress/deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
service/ingress-nginx-controller created
service/ingress-nginx-controller-admission created
deployment.apps/ingress-nginx-controller created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
ingressclass.networking.k8s.io/nginx created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created

⏳ Wait condition to met
kubectl wait --namespace ingress-nginx --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=120s
pod/ingress-nginx-controller-697950d654-2m7zc condition met

```


### Provide registry

This section we need to provide in order to tag our local images. It will ask you for input based on you desired registry. In this case Dockerhub as you can see below

```
⬇️ Configure DockerHub registry
Provide your DockerHub account: igor992

⬇️ Updating configuration with registry: igor992
✅ Registry configuration updated

```

*<span style="text-decoration:underline;">NOTE:</span>* For this demo, as you will see later we will not push those images, instead we will use them locally from Kind cluster. If you want for any reason to push those to Dockerhub, you will need to prepare [connection](https://docs.docker.com/reference/cli/docker/login/) and change **skaffold.yaml** at section *local.push = true*

As placeholder code has *&lt;registry>* on two location [helm values](https://github.com/Igor992/skaffold-demo/blob/main/helm/values.yaml) and [skaffold](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml)

When you provide above information those will be changed. 



### Generate images

Now that we have a cluster ready for usage, we need to prepare images locally for our demo application. \
For this we use **make skaffold** 



```
➜ skaffold-demo git:(main) ✗ make skaffold

🧱 Using skaffold to generate starting images
cd voting-app && \
  export IMAGE_TAG=latest && \
  skaffold build --profile vote-images,--seed-image && \
  skaffold build --profile vote-images,--seed-image

Generating tags...
 - igor992/result -> igor992/result:latest
 - igor992/vote -> igor992/vote:latest
 - igor992/worker -> igor992/worker:latest

Checking cache...
 - igor992/result: Not found. Building
 - igor992/vote: Not found. Building
 - igor992/worker: Not found. Building

Starting build...
Found [kind-develop] context, using local docker daemon.
Building 3 artifacts in parallel
Building [igor992/result]...
Target platforms: [linux/arm64]
#0 building with "default" instance using docker driver
```


As you can see it will use at this point something new as **skaffold build –profile**

This is coming from **skaffold.yaml** [spec](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L73-L76) that we have under **voting-app** directory. \
Here **build** act as control how artifact will be build and **–profile** control order of building those artifacts, as we have two profiles minus sign e.g. **-seed-image** excludes that [profile](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L105-L108) to be executed.


###  
Trust development cluster

We will now add these locally trusted certificates for our development application by **make certs**


```
➜ skaffold-demo git:(main) ✗ make certs

🔐 Make locally trusted development certificates
cd .tls && \
  mkcert "*.kind.local" && \
  kubectl create namespace dev && \
  kubectl --namespace dev create secret tls demo-cert \
    --key=._wildcard.kind.local-key.pem \
    --cert=._wildcard.kind.local.pem && \
  mkcert --install

Created a new certificate valid for the following names
 - "*.kind.local"

🔎 Reminder: X.509 wildcards only go one level deep, so this won’t match a.b.kind.local 🧠

✅ The certificate is at "./_wildcard.kind.local.pem" and the key at "./_wildcard.kind.local-key.pem" 🗝️
📅 It will expire on 1 June 2027 🎉

namespace/dev created
secret/demo-cert created
The local CA is already installed in the system trust store! 👍
The local CA is already installed in the Firefox trust store! 👍
The local CA is already installed in Java’s trust store! 👍

```




**I’ll not explain above part on this blog*

Last one in order to use configured ingress with trusted certificates we need to change **/etc/hosts** over **make hosts**. 

This will require from you to allow this (type your password) so we can add two entries as

 
**127.0.0.1 	dev-vote.kind.local dev-result.kind.local**


## Deploy application

 
**Application is for demo purpose only  and not focused on best-precites on Docker images and other container topics.*

Under the **voting-app** directory you will see **skaffold.yaml** [definition](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml). Let’s give a short introduction into this configuration before we use it.

In this demo we are going to use stable *skaffold/v3* schema version followed by three *profiles*.



* local-develop
* vote-images
* seed-image 


Profile *[vote-images](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L73)* and *[seed-image](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L105)* we already used over **make skaffold** step before.  \
This prepared locally for us three images for *result*, *vote* and *worker* services and one more *seed-data*, to be able to provide fake clicks and populate the database.



```
➜ voting-app git:(main) ✗ docker images -a

REPOSITORY        TAG       IMAGE ID       CREATED          SIZE
igor992/seed-data  4d58b8c   4d58b8c6cf34   18 minutes ago   132MB
igor992/seed-data  latest    4d58b8c6cf34   18 minutes ago   132MB
igor992/worker     247d9c7   247d9c79b44f   18 minutes ago   139MB
igor992/worker     latest    247d9c79b44f   18 minutes ago   139MB
igor992/result     7d6ef7e   7d6ef7e45c8e   18 minutes ago   138MB
igor992/result     latest    7d6ef7e45c8e   18 minutes ago   138MB
igor992/vote       5706951   570695168d11   18 minutes ago   184MB
igor992/vote       latest    570695168d11   18 minutes ago   184MB
kindest/node       <none>    9ba0a97d7488   2 weeks ago      1.68GB
```


In order to deploy the whole stack on our local cluster, we are going to use a *local-develop* [profile](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L6) over command **skaffold dev**



```
➜ voting-app git:(main) ✗ skaffold dev

Generating tags...
 - igor992/result -> igor992/result:8181ec5
 - igor992/vote -> igor992/vote:8181ec5
 - igor992/worker -> igor992/worker:8181ec5

Checking cache...
 - igor992/result: Found Locally
 - igor992/vote: Found Locally
 - igor992/worker:
```


As we already prepared images before, it will use local ones. 
You can see part when we hit the deploy phase of our configuration defined under *[skaffold.yaml ](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L40)* file (*Starting deploy…*) 
Images will be loaded under a local cluster, in our case Kind.  
To be able to check those use command below \
**docker exec -it $(kind get clusters | head -1)-worker crictl images**

This will interact with one of the nodes locally and print images that’s there present. 



```
➜ skaffold-demo git:(main) ✗ docker exec -it $(kind get clusters | head -1)-worker crictl images

IMAGE                                   TAG                                         IMAGE ID            SIZE
docker.io/igor992/result                15439a086162c0cc9c8ebc01a2b789b730175785e5a2faf7eb550b51cc9407   138MB
docker.io/igor992/vote                  4d861b51985c372cbad13b79b9f9d8e24eb47e64bb172c947528b8009e9799   184MB
docker.io/igor992/worker                1865a8b7f235469d1124e9105d934874bb1bef86793e                      139MB
docker.io/kindest/kindest               v1.32.0@sha256:a8abac                                             1.68GB
```


**There are other images also present in node*

Wait a bit to stabilize deployment as we have checks that perform if redis and database are first ready for connection.


```
Happy Helming!
Waiting for deployments to stabilize...
 - dev:deployment/dev-worker is ready. [1/5 deployment(s) still pending]
 - dev:deployment/redis is ready. [2/5 deployment(s) still pending]
 - dev:deployment/dev-result is ready. [3/5 deployment(s) still pending]
 - dev:deployment/dev-vote is ready. [1/5 deployment(s) still pending]
 - dev:deployment/db is ready.

Deployments stabilized in 1.144 second

Port forwarding service/redis in namespace dev, remote port 6379 -> http://127.0.0.1:6379
Port forwarding service/db in namespace dev, remote port 5432 -> http://127.0.0.1:5432

Listing files to watch...
 - igor992/result
 - igor992/vote
 - igor992/worker

Press Ctrl+C to exit
Watching for changes...
```


At this point skaffold will perform next job for development lifecycle



* allow developers access to redis and database locally
* constantly loop over changes under three services
    * if there is any code change made by developer it will sync those


```
Syncing 1 files for igor992/vote:4d861b51985c372cbad13b79b9f9d8e24eb47e64bb172c947528b8009e9799
Watching for changes...

[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [18] [INFO] Worker reloading: /app/app.py modified
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [19] [INFO] Worker reloading: /app/app.py modified
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [20] [INFO] Worker reloading: /app/app.py modified
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [21] [INFO] Worker reloading: /app/app.py modified
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [22] [INFO] Worker exiting (pid: 19)
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [23] [INFO] Worker exiting (pid: 20)
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [24] [INFO] Worker exiting (pid: 21)
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [25] [INFO] Booting worker with pid: 24
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [26] [INFO] Booting worker with pid: 25
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [27] [INFO] Booting worker with pid: 26
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:14 +0000] [27] [INFO] Booting worker with pid: 27
```



In order for this to work, under the hood it uses the **kubectl cp** command and if you ever worked with this one, it is [required](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cp/#examples) to have **tar** binary installed under a running container. 
Another catch is to allow the service to reload its process on file changes. 
This will add *<span style="text-decoration:underline;">hot code reloading</span>* ability so that we can live see changes after sync. 
For this we always have separate image that will skaffold use during development and not the same one as we bake for the production best-practice usages. 
In our case as we use *[gunicorn](https://docs.gunicorn.org/en/latest/settings.html#reload)* we added flag --reload to support this process changes.


## Simulate voting

At this point as this dummy application supports one vote per time, we will simulate that we have “external” users to perform this voting for us. \
For this we first needs to push image inside Kind over  \
**kind load docker-image igor992/seed-data -n develop** \
where it will add this on each nodes for usage



```
➜ skaffold-demo git:(main) ✗ kind load docker-image igor992/seed-data:4d58b8c6cf34 --name develop

Image: "igor992/seed-data:4d58b8c6cf34" with ID "sha256:fbf75323215720f3b3c3143c1dd73b1b09cba97f5959349614ecaf7d4a5ea0e7" not yet present on node "develop-control-plane", loading...
Image: "igor992/seed-data:4d58b8c6cf34" with ID "sha256:fbf75323215720f3b3c3143c1dd73b1b09cba97f5959349614ecaf7d4a5ea0e7" not yet present on node "develop-worker", loading...
```

Then just use command

**kubectl run seed-data --namespace dev --rm --tty -i --restart='Never' --image igor992/seed-data:latest**

 \
Wait a bit and it will populate “fake” votes on our application. That will be shown as result over *[https://dev-result.kind.local](https://dev-result.kind.local) \
*And if you really want jump into locally database to validate those also \
**psql --host localhost --port 5432 --no-password --username postgres \
SELECT id,vote FROM public.votes;**

To prove that redis is also there use **redis-cli INFO server** or **redis-cli ping** to get response as **pong** 



## Conclusion

With this presentation I wanted to bring closer to developers a new approach on how development can be faster in terms of cloud computing service. If this implements another layer of shit-left practice, developers get feedback much faster even before the first real image gets deployed as permanent to be shared with the rest of the team.

With this said, keep learning each day something different and new is what makes a cloud native experience more fun.

For more information on [Kubernete]( https://kubernetes.io/)s and [Skaffold](https://skaffold.dev/), feel free to visit their official websites, which I also referenced while writing this blog.

 \
Until my next [blog,](https://cyberlab.rs/blog) Happy Helming! 👋


We're Wired In.
Latest news.

One Firewall to Rule Them All:Hub & Spoke on AWS

SuperPlane Review:We Tested This DevOps Orchestration Tool Both Ways

ECS Managed Daemons:The DaemonSet Equivalent ECS Was Always Missing

Running for Neda: The Story Behind CYBERLAB's 1,237km

How AI Is Changing the Way We Write Code:Insights from a Community Talk on Claude Code and AI-Assisted Development

Claude Code 101:From Zero to Full Potential

CYBERLAB Achieves:AWS Select Tier Services Partner Status

New Year’s Charity Pub Quiz: Supporting Minja, Strahinja, and Vukašin

Kubernetes Development: Building with Skaffold

ELEVATE
YOUR
CLOUD.

We're Wired In. Latest news.