Stackshift

Hosting with transparent pricing and zero bill shock. Frontend + Backend + DB on one platform.

[Stackshift @StackshiftCloud]

Introducing Stackshift

We're building the hosting platform developers deserve.

Here's why ↓

[Stackshift @StackshiftCloud]

@Crownzdesigns @_fusionTech You’re welcome.

[Stackshift @StackshiftCloud]

@Crownzdesigns @_fusionTech You can check it out here https://t.co/tE174VpF0F

[Faceless Dev 🎭 @_fusionTech]

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.

[Faceless Dev 🎭 @_fusionTech]

https://t.co/J2ZiVymiAv

[Stackshift @StackshiftCloud]

We are up and running!! 🚀

[Faceless Dev 🎭 @_fusionTech]

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:
https://t.co/AWoboSSFrk
You can also checkout StackShift here:
https://t.co/zLrztszIDt

[Faceless Dev 🎭 @_fusionTech]

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:
https://t.co/AWoboSSFrk
You can also checkout StackShift here:
https://t.co/zLrztszIDt

[Stackshift @StackshiftCloud]

#NewProfilePic

[Stackshift @StackshiftCloud]

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.

[Faceless Dev 🎭 @_fusionTech]

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

[Faceless Dev 🎭 @_fusionTech]

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.

[Faceless Dev 🎭 @_fusionTech]

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

[Faceless Dev 🎭 @_fusionTech]

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

[Faceless Dev 🎭 @_fusionTech]

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).

[Stackshift @StackshiftCloud]

Built for:
- African indie hackers
- Bootstrapped founders who hate surprise bills
- Agencies managing multiple client projects
- Anyone tired of platform juggling

Launching soon

[Stackshift @StackshiftCloud]

Introducing Stackshift

We're building the hosting platform developers deserve.

Here's why ↓

[Stackshift @StackshiftCloud]

Stackshift fixes this:

✅ Transparent pricing (see exactly what you'll pay)
✅ Full-stack on one platform (frontend + backend + DB)
✅ Africa-first infrastructure
✅ 5-minute deploys from GitHub

No DevOps degree required.