As a backend engineer, deploying a simple static site is one thing. But what about a "real" application? I'm talking about a Go (Gin) API that needs to talk to a Postgres database and a Redis cache.
On a traditional cloud, this is where the "infrastructure tax" kicks in. I'd be setting up VPCs, subnets, security groups, and IAM rules just to get my services to talk to each other.
I wanted to see if the promise of Viduli held up. I deployed a simple Go task-manager app called "Frogify," and this is how it went.
Step 1: Provisioning the Backend (in 3 Clicks)
I started in an empty Viduli project. I needed three services: my Go app, a Postgres DB (using Orbit DB), and a Redis cache (using Flash Cache).
This entire process was just clicking "Launch Resource" three times. Instead of a YAML headache, I was just selecting my region, vCPU, and RAM.
In about 90 seconds, my entire backend stack was provisioned and visible on the dashboard.
This visual graph is more than just a nice UI; it shows that all three services are up and healthy. Frogify (my Go app), Frogify-db (Postgres), and Frogify-cache (Redis) are all running.
Step 2: Connecting the Services (No YAML)
This is the part that usually trips people up. How does my Frogify app find the database? How does it get the password?
This is where I was most impressed. Viduli automatically creates all the connection secrets for the database and cache.
I simply went to my Go app's Environment tab and created a DATABASE_URL and REDIS_URL. The Viduli UI let me link these directly to the internal URLs of my new database and cache. No manual copying and pasting of passwords, which means no way to get it wrong.
Step 3: Deploy and Done.
With the environment variables set, Viduli automatically triggered a new deployment of my Go application.
I clicked over to the "Logs" tab and watched. The app booted, my godotenv line (correctly) found no .env file, and it read the new production variables.
The logs immediately showed the Gin server listening on port 8080, my database migration running, and my API endpoints being registered. It was already live and handling requests.
Conclusion
What took three paragraphs to write took about minutes in reality.
This is the PaaS promise fulfilled. I was able to focus 100% on my Go code. Viduli handled the entire backend stack, from provisioning to networking to deployment and made the most complex part (service-to-service communication) a simple, two-click connection.