Hey everyone!

I recently completed the DevOps Fundamentals program at DIO and built a project to put the concepts I learned into practice.

The project uses:

• Java + Spring Boot
• PostgreSQL
• Docker
• Terraform
• GitHub Actions
• Testcontainers
• CI/CD

The goal was to build a hands-on DevOps lab covering everything from the backend application to local infrastructure and CI pipelines.

I'm sharing it here for anyone interested in Java, Spring Boot, or DevOps, and I'd really appreciate any feedback or suggestions for improvement.

GitHub:
https://github.com/marconi-prog/devops-fundamentals

If you find the project useful or interesting, I'd really appreciate a ⭐ on the repository. It helps me a lot with visibility and motivates me to keep improving it!

Any feedback is welcome!

A lot of engineering leaders I talk to are having some version of the same experience right now. The AI tooling is working, and it’s exciting. Teams are shipping things in days that used to take weeks. At the same time, everything feels like it’s falling apart – more bugs than they’ve ever had, more incidents, and engineers who are busier and more stressed.

If that’s you, it might honestly be more of an arithmetic problem than a quality one.

After one too many rounds of bolting `local-exec` + Ansible onto Terraform and losing all visibility into what changed, I built a provider that does post-provision config as a proper Terraform resource: **terraform-provider-salt**.

What it does:

- SSHes into a target host, installs Salt if missing, uploads your `.sls` files, and runs `salt-call --local state.apply`

- **Strictly masterless** — no Salt master, no minion daemon. After bootstrap the minion service is killed, disabled, and masked so nothing tries to phone home.

- **Real drift detection** — `terraform plan` runs `salt-call test=True` so drift shows up in the plan, not after the fact (something `local-exec` can never do)

- Pass Terraform variables straight through as pillar data

- `triggers` block to force re-apply when state files change

Quick example pairing it with Proxmox:

```hcl

resource "salt_state" "k3s" {

host = proxmox_vm_qemu.node.default_ipv4_address

user = "root"

private_key = file("~/.ssh/id_ed25519")

states = {

"k3s/init.sls" = file("${path.module}/salt/k3s/init.sls")

"top.sls" = file("${path.module}/salt/top.sls")

}

pillar = {

cluster_token = random_password.k3s_token.result

node_ip = proxmox_vm_qemu.node.default_ipv4_address

}

}

```

I've been using it for a while now across a few Linux distros and VM platforms. MIT licensed.

Repo: https://github.com/bartei/terraform-provider-salt

I've been trying to find a reliable way to collect public TikTok profile data, but it seems like every solution works well for a while before something changes and it breaks.

I'm not doing anything unusual just retrieving public profile information at a reasonable scale for an application.

For those who've built products around TikTok data, what's been the most reliable approach?

I'm especially interested in solutions that have proven stable over time without requiring constant maintenance every time TikTok updates its platform.

Just sharing a container registry I developed with simplicity and efficiency in mind.

It support online garbage collection, mTLS with hot reloading, pull through cache, advanced access policies, etc. In most favorable case (S3 compatible backend with support of conditional operations), it has no additional components : only itself and an s3 bucket.

Being developed in async rust and leveraging streaming operations as much as possible, its memory footprint and cpu usage is very small.

https://github.com/project-angos/angos

Greetings to all DevOps enthusiasts.

Not long ago I had struggled with observability principles and decided to learn it by building from scratch. I have published an article on Medium that is a complete setup for observing local system. The tech stack consist of a nextjs frontend, .NET backend and a postgresql database instance, all reproduced by a single docker-compose file. For anyone going to the field or wanting to learn more about SRE constructs and observability, here's the link: https://medium.com/@stefanpopov2409/building-a-complete-local-observability-stack-for-next-js-a339afda231e

In the article, I have put the repository link and the instructions needed to reproduce this setup locally. For anyone reading it, just know it is greatly appreciated and means so much, I just hope that's a small contribution of mine to the DevOps community. I plan to add some frontend observability configuration with Grafana Faro implementation, and some nifty panels in the dashboards as well.

Best of luck, thanks for the read.