Sabitlenmiş Tweet
Faceless Dev 🎭
47.2K posts
Faceless Dev 🎭
@_fusionTech
Founder @stackshiftCloud Email: [email protected]
Bikini Bottom Katılım Ekim 2018
2.2K Takip Edilen2.5K Takipçiler
For my Wordpress people.
StackShift now supports a full WordPress theme and plugin release flow.
You can connect your WordPress plugin or theme repo to StackShift, StackShift detects it, run the needed build steps, package it into a release, promote it through draft, beta, and stable channels, then install that exact release into a running WordPress site hosted on StackShift.
That means you can go from repo to tested WordPress extension without the usual manual loop of:
export zip,
open wp-admin,
upload plugin/theme,
activate it,
check if the site broke,
try to remember which version you installed.
The flow is now much cleaner:
connect the plugin or theme repo,
let StackShift build and package it,
preview it in an isolated WordPress environment,
promote it to a release channel,
install that release into your running WordPress site,
track what was installed.
This is especially useful if you build WordPress sites for clients.
You can keep the client’s WordPress site hosted on StackShift, work on custom plugins or themes, push to GitHub, test releases separately, and then install the exact version into the live site when it is ready.
WordPress plugins and themes are software.
They deserve a real release workflow, not random zip uploads and “hope this is the latest version” energy.
That’s what we’re building into StackShift.
stackshift.cloud
English
@AllNet001 @bahdcoder You should check out @StackshiftCloud , no matter what happens, your projects, stay running.
English
Deploying millions of apps and still on Google Cloud free trial 😭
Railway@Railway
The Railway dashboard is currently unavailable, and all running Railway services are down. We're working with our upstream provider to restore service. Updates: status.railway.com
English
StackShift now has AI agents for real cloud work:
Deploy Agent to redeploy, rollback, and inspect releases.
Debug Agent to diagnose failed builds and open patch PRs.
Database Agent to inspect DB health and plan safe actions.
WordPress Agent to create and manage Wordpress websites.
The goal is simple: when something breaks, StackShift should not just show logs. It should help fix it.
You can check it out on stackshift.cloud
English
Please checkout stackshift.cloud, it’s very cheap and your plan comes with email for and assets, you don’t have to pay extra for those with very generous daily limits. You can plug in your VPS or cloud account and deploy straight to your own server if you don’t want to use StackShift’s server.
English
I am part of the poors, so here are engineering decisions I will never make unless I raise funds:
- AWS/Vercel for hosting
- Sentry for error tracking
- Any SAAS tool with p/user/p/month pricing
- Posthog for analytics (Yes o)
- Mailchimp/Postmark for emails
English
Some devs don’t need another VPS, they need a control plane that understands how they actually ship.
Start deploying on StackShift today.
stackshift.cloud
English
I'm judging you like mad if your app can't handle 200 users even if they all sign up within 10 minutes. 200 is baby number when it comes to scale and you don't need to optimize anything to scale to 200 users.
0𝕏.Glo🧬@glocryptofuture
Lmao, systems are more fragile than you think, 200 users registering in one short burst of time na big deal if you no handle am well. E get time wey I Dey always set my database pool to 20. And I go still dey make unnecessary db requests 😂 Also ram and cpu na big deal too.
English
Faceless Dev 🎭 retweetledi
The problem started when I said "e choke" in a meeting.
My colleague Linda from accounting paused mid-slide. She said, Is everything okay with your throat?
I said, No, Linda, it means the numbers are impressive.
She wrote that down. She literally wrote it down. Three days later she told our boss the quarterly projections were choking her. HR got involved.
I work in Toronto, in a glass office where the only other Nigerian is a man named Tunde who has completely assimilated. The kind who pronounces "schedule" like he invented the language. He avoids me in the breakroom because I remind him of jollof rice and his mother's expectations.
So I suffer alone.
Last month I told a project manager that the deadline was giving me wahala. He emailed my supervisor asking if wahala was a vendor we needed to loop in. I now have a meeting on Friday about clarifying communication styles.
The worst was when I said "abeg" to an intern. She thought it was a new productivity tool. She searched the internal software catalogue. By Tuesday, IT had opened a ticket.
I tried explaining slangs to my coworkers once. Big mistake. Now every Monday morning, Kevin from sales greets me with "How far?" but he says it like "How far, my good man?" and waits for a response as if I am a foreign exchange student he is sponsoring.
Linda has started saying "e choke" whenever she completes a spreadsheet. She does finger quotes around it. She has made a PowerPoint slide titled "Nigerian Business Expressions for Cross-Cultural Synergy."
I sat Tunde down last week. I said, Tunde, you need to help me. They've weaponized our entire lexicon.
He adjusted his cardigan. He said, I'm sorry, I don't really speak it anymore.
I said, You were born in Owerri.
He said, That was a long time ago. He stirred his green tea. No sugar. No milk. Just assimilation and regret.
Yesterday I overheard my boss on a client call. She said the deal was giving her gbe body. I had told her "gbe body" means being alert. She now uses it to mean proactive. The client loved it. They want it in the brochure.
I have created a monster.
The office Christmas party is next week and Kevin told me he is planning to say "shey you dey whine me" during his toast. He has been practising pronunciation with a YouTube video titled "Speak Nigerian in 5 Minutes."
I will not be attending.
Every diaspora office has one person fighting for their slangs and one Tunde drinking green tea pretending he cannot remember the taste of chin chin.
English
It’s been really hard showing up online and staying consistent lately, especially when I haven’t been feeling my best.
This honestly feels really unfair to me.
Crownz | AI & Design@Crownzdesigns
I woke up to @Upwork taking away my Top Rated badge even though I met all the criteria and maintained everything on my end. I’ve already reached out to support but no response yet.
English
Faceless Dev 🎭 retweetledi
Faceless Dev 🎭 retweetledi
@Crownzdesigns Beautifully done.
Bring this to @StackshiftCloud 🥹
English
Meet Moodmate, your creative AI canvas for better design decisions.
Generate color directions, discover font pairings, get relevant keywords, and explore art direction all in one place.
Built this using Antigravity.
Link in the comments 👇
Crownz | AI & Design@Crownzdesigns
Currently building an Ai powered creative Canvas on Antigravity
English
After StackShift Mail, the next thing I kept thinking about was file storage.
Because almost every real app eventually needs to handle files.
User avatars.
Product images.
PDF invoices.
CSV imports.
Generated reports.
Media uploads.
Private documents.
Downloads.
Thumbnails.
Image variants, etc.
So I started building StackShift Assets.
Not as a wrapper around S3.
Not as a wrapper around Cloudinary.
Not as a wrapper around R2.
The goal is StackShift-owned asset infrastructure for apps.
The flow is simple:
App uploads file
→ StackShift stores asset metadata
→ file is written to StackShift-owned storage nodes
→ asset gets an ID
→ CDN URL or signed URL is generated
→ image variants can be created
→ processing jobs can run
→ usage and access can be tracked
And again, StackShift Jobs becomes the engine behind a lot of this.
Uploading a file is one part.
But real asset infrastructure needs background work:
generate thumbnails
create image variants
scan files
replicate files
repair missing replicas
purge CDN cache
process large uploads
clean up expired assets
emit asset events
update metadata safely
That kind of work should not live inside a single HTTP request.
So StackShift Assets uses the same durable execution idea:
Upload the file now.
Process it in the background.
Retry failed work.
Track every step.
Repair when something goes wrong.
That is where StackShift Jobs becomes powerful.
It is not just a queue.
It is the system that makes platform features reliable.
So far, the direction for StackShift Assets is:
asset uploads
asset metadata
public/private visibility
CDN delivery
signed URLs
direct browser uploads
image transformations
thumbnails
asset variants
custom domains
cache purge
lifecycle rules
malware scanning path
asset events
usage tracking
replication
repair jobs
storage-node health
private asset access control
The architecture is also not “store a URL from another provider and pretend it is ours.”
The idea is:
Browser/SDK
→ StackShift Assets API
→ StackShift asset gateway
→ metadata in StackShift database
→ StackShift-owned storage nodes
→ CDN in front for fast delivery
Cloudflare can sit in front as CDN/edge infrastructure, but the product is not just a Cloudflare wrapper.
The asset gateway becomes the policy brain:
Is this asset public?
Is this signed URL valid?
Is this file scanned?
Which replica should serve it?
Should the CDN cache it?
Should a variant be generated?
Should access be denied?
Should an event be emitted?
That is what makes it a real platform feature.
StackShift Mail is about app communication.
StackShift Jobs is about reliable background execution.
StackShift Assets is about storing, processing, and delivering files.
The common idea is the same:
Developers should not have to assemble five different services before their app can do normal production things.
They should be able to deploy the app, send the email, run the job, upload the asset, and track what happened.
English
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.
English
Faceless Dev 🎭 retweetledi
