Introducing Stackshift We're building the hosting platform developers deserve. Here's why ↓

We steady cooking!!

I remember when I started building StackShift and was using SES for emails. When I got closer to launch, I applied for SES production access so StackShift could send real emails to users, not just the one verified email I was using in sandbox. AWS kept rejecting it. They were asking for so many things I didn’t have yet: clearer use case, sending patterns, bounce handling, complaint handling, suppression strategy, opt-in details, domain setup, abuse prevention, and all the things you’re expected to already understand before you can even send email properly. At that point, I moved to Resend so I could keep shipping. But the thought stayed in my head: Why is this not a StackShift feature? If StackShift is supposed to help developers deploy and run real applications, then transactional email is part of that story. Apps need to send emails for several things. So instead of depending on yet another external service, I decided to build StackShift Mail. Not as a wrapper around SES. Not as a wrapper around Resend. Not as a wrapper around Mailgun. Actual StackShift-owned mail infrastructure. The flow now is: App calls StackShift Mail → message is stored → send job is queued → worker composes the email → DKIM/signing path is handled → Postfix hands it off → attempts/logs/status are tracked → failures can be retried → bounces can be processed → bad recipients can be suppressed And the most interesting part is that StackShift Mail is powered by another StackShift primitive I already built: StackShift Jobs. StackShift Jobs is the durable background execution system I built for work that should not die when the request ends. Instead of doing everything inside an HTTP request, you can offload work to StackShift Jobs and let it handle retries, attempts, logs, delayed execution, failures, and recovery. That means Mail does not have to block the user’s request. When you call mail.send, StackShift can accept the message, queue the work, process it safely, retry temporary failures, and keep a full trail of what happened. That same Jobs system also powers things like OTP expiry, webhook delivery retries, bounce processing, scheduled sends, batch sending, and reputation evaluation. This is why building platform primitives matters. One primitive unlocks another. So far, StackShift Mail now has: transactional email sending API-key scoped usage message persistence send attempts logs Postfix handoff DKIM/signing integration path customer domain verification SPF/DKIM/DMARC/return-path checks sender domain enforcement bounce handling hard/soft bounce classification suppression lists automatic blocking of bad recipients OTP send and verify OTP expiry max attempts resend cooldowns hashed OTP storage templates template versions backend template rendering template preview test sends sendTemplate API mail lifecycle events webhooks webhook signing webhook retries message timeline reputation checks sending limits warmup stages domain reputation scheduled emails transactional batches attachments inbound mail foundation analytics, etc. This started because I got blocked trying to send emails for StackShift. Now it’s becoming a full StackShift product. Deploy the app. Run the jobs. Send the emails. Track what happened.

We are up and running!! 🚀

Today I'm launching StackShift. StackShift is an infrastructure ownership platform for deploying, operating, and managing modern software from one control plane. It supports Node.js, Python, Go, Rust, PHP, Laravel, Ruby, static sites, Docker-based apps, Svelte/SvelteKit, worker services, multi-container stacks, and web3-style build workflows like Hardhat, Truffle, Foundry, and Anchor. But StackShift is not just about deployment. It brings together hosted infrastructure, bring-your-own server, bring-your-own cloud, bring-your-own SMTP or outbound email provider, database provisioning, domain purchases, DNS management, email hosting, WordPress and other deployable templates, logs, metrics, backups, billing, teams, and AI-assisted failure diagnosis. The thesis is simple: Modern teams should not have to choose between convenience and ownership. StackShift gives teams one place to run their software infrastructure, whether it lives on StackShift, their own server, their own cloud account, or their own providers. I wrote more about the product direction, the ownership model, and what I’m building here: x.com/_fusionTech/status/204… You can also checkout StackShift here: stackshift.cloud

Moved Stackshift from being AWS wrapper to having its own dedicated server. That migration was a tough one, I was venturing into a very different path I haven’t seen before but at the end of the day and hours of locking myself out of my server (Very funny experience), I did it.

Trying to run indexing for @StackshiftCloud RAG for build diagnosing AI and the API kept crashing. Was hitting Voyage AI rate limit of 3RPM. I had to tell Claude to write me a script that will run the indexing with wait time after each chunk to avoid the limit.

I spent days debugging our database provisioning system and fixed 9 major bugs!  The culprits: PostgreSQL failing on EBS lost found dirs. Redis health checks missing auth. File ownership chaos (root vs db users). Config env var mismatches. Docker compose overrides. Now all 3 DB types (PostgreSQL, MySQL, Redis) provision flawlessly with EBS storage! Sometimes the best debugging sessions are the ones that uncover a whole cascade of issues. Each fix revealed the next problem  Up next adding Team management feature and payment system. #DevOps #Debugging #PostgreSQL #Redis #AWS #EBS #Docker

UPDATE: My Go PaaS journey continues... Since my last update, I've been burning through those AWS credits and the platform has evolved significantly. Here's what's new: Enhanced Authentication: GitHub OAuth integration Account linking (email users can connect GitHub) JWT refresh tokens Advanced Project Management: Preview deployments for PRs Build & deployment history Real-time logs streaming Rollback to any previous deployment Project metrics & monitoring Developer Experience: Environment variables management Custom domain support with auto-SSL Build cancellation & timeouts Log downloads & streaming Infrastructure Additions: Managed PostgreSQL databases Prometheus metrics collection Rate limiting & security middleware Threshold-based alerting system Notifications: Real-time notifications via SSE Email alerts (AWS SES) User notification preferences Monitoring & Limits: Deployment frequency limits Build timeout enforcement Application health checks Resource usage tracking The deployment flow remains the same, but now with preview environments, better monitoring, and a much more robust developer experience! #golang #aws #paas #devops #buildinpublic

I was thinking of what to do with my free time and boom! I decided to learn Go but with a twist. I am not just learning, but build something while at it. Got a $100 free credits from AWS to burn so I started building a PaaS. Infrastructure: Docker-based CI/CD pipeline(API worker), GitHub webhook integration for automated deployment, AWS ECR for container image storage, EC2 deployment with SSH automation, Caddy reverse proxy with automatic SSL certificates. Features Implemented so far: User auth, project management (CRUD operations), automated builds(Docker image creation), ECR auto creation with prefix, multi platform support (Node, Go, Python & static sites).