ezomfy
All posts
September 23, 20267 min read

Shopify automation with no hosting and no monthly fee

The monthly fee in most integration quotes is hosting, and hosting exists to accept inbound connections. Reverse the direction and the entire category of cost disappears.

A

Ashraful

Shopify Select Partner

Short answer: an integration that only talks outward — polling Shopify, acting locally — needs no server, no domain and no hosting bill. It runs on a machine you already own, behind your existing firewall, with nothing exposed to the internet. The moment something needs to reach in to your code — a webhook, an embedded admin page, an OAuth callback — you need a public address, and the bill starts. Whether you need that is an architecture decision, not a given.

Every quote for a Shopify integration seems to arrive with a monthly number attached. Hosting, a database, a queue, monitoring, a domain, certificates.

For a large class of automation, all of that is optional, and the version without it is more reliable rather than less.

Why do most integrations need hosting?

Not because the work is heavy. Because of the direction the connection runs.

A webhook is Shopify calling you. To be called, you must be reachable from the public internet: a domain, a valid TLS certificate, an always-on listener. An embedded app page inside the Shopify admin is the same requirement — Shopify's iframe loads your URL. OAuth needs a callback address Shopify can redirect to.

Every one of those is inbound. Inbound requires an address, an address requires hosting, and hosting requires a bill, a certificate that expires, and something to monitor.

Turn the direction around and the entire category of cost disappears. A process that polls Shopify makes outbound HTTPS requests, which every firewall already allows and which need no address of their own. It can run on a laptop in a workshop, a NAS, a spare desktop, a Raspberry Pi. Nothing is exposed, because there is nothing listening.

What you can build with no server at all

More than people assume. If the work happens on a machine you own, and nothing outside needs to reach in:

  • Order to production. Poll for paid orders, download attached artwork, validate it, file it, hand it to a print queue or a RIP hot folder.
  • Inventory sync against a local system — an ERP, a spreadsheet, a warehouse database on the same network.
  • Fulfilment. Push tracking numbers back to Shopify from a courier's desktop software.
  • Reporting. Pull yesterday's orders, produce a file or an email, on a schedule.
  • Catalogue maintenance. Bulk price or tag updates from a local source of truth.
  • File processing. Anything involving large files, which is also the case where local processing is genuinely faster than uploading to a cloud service and back.

All of it is a scheduled process making outbound calls. No inbound anything.

What genuinely needs hosting?

Be clear about the line, because building the wrong side of it is expensive either way.

  • An embedded admin page. If staff need a screen inside the Shopify admin, that page is loaded from a URL and the URL must be public.
  • Anything in the App Store. Public distribution requires OAuth, webhooks and a hosted app. Not negotiable.
  • Storefront-facing features. Anything a customer's browser touches during a purchase.
  • Sub-second reaction. If a minute of delay is unacceptable, polling will not do and you need webhooks, which need an address.
  • Multiple locations sharing state. Two sites coordinating need something in the middle.

Note what is not on that list: most internal automation. The work your staff currently do by hand almost never needs an inbound connection.

Local, poll-basedHosted service
Monthly costNone$10 to $200+
Domain requiredNoYes
TLS certificateNoYes, renewing
Exposed to internetNothingThe endpoint
Works behind firewallYesNeeds config
Survives being offlineYes, catches upDepends
LatencyYour poll intervalSeconds
Embedded admin UINoYes
App Store distributionNoRequired

The admin panel question

The usual objection: without hosting, how does anyone configure or watch the thing?

A local web interface. The process serves a small admin panel on localhost, or on the local network if several people need it. Settings, logs, the queue, failed items, a retry button.

It is a real interface with a real UI. It is simply not on the public internet, which is the entire point — no authentication exposure, no attack surface, no certificate, no bill. Anyone on the machine or the local network opens a browser and it is there.

For the print shop build we did, the panel shows the order queue, which files failed validation and why, and lets someone retry or release a held job. It runs on the same PC that drives the RIP. Nobody has ever asked for it to be on the internet.

What does it actually cost to run?

Nothing recurring, and that is not a simplification.

  • Compute: a machine that already exists and is already on.
  • Storage: the local disk, unless files need to go elsewhere.
  • Network: outbound HTTPS on the connection you already pay for.
  • Domain: none.
  • Certificates: none.
  • Shopify API: free within rate limits, which a sensible poll interval is nowhere near.

The costs that remain are the fixed build, and maintenance. Budget a few hours a year: Shopify ships two API versions annually and deprecates on a published schedule, so a client running a custom app should expect to look at it once a year, not never. Anyone promising zero maintenance forever is describing something that will break quietly in about eighteen months.

The honest trade-offs

One machine is one point of failure. If it dies, the automation stops until someone notices. Acceptable when the machine is the thing doing the work anyway — if the RIP PC is down, nothing is printing regardless.

Monitoring is on you. No hosting provider dashboard. Build a heartbeat: the process reports a successful run somewhere you will actually look, and alerts on the absence of one. Silence looks identical to a quiet day, which is the failure mode that catches everyone.

Backups are on you. If the process holds state locally, that state needs backing up like anything else.

Updates are manual. No CI pipeline pushing to a server. Usually fine at this scale, occasionally annoying.

None of these are hypothetical, and none of them cost $100 a month to solve.

What should you ask about a quote?

"Why does this need to be hosted?"

If the answer is that staff need a screen inside the Shopify admin, or it is going in the App Store, or a customer's browser touches it — fair, and the hosting is real.

If the answer is vaguer than that, the integration may not need an inbound connection at all, and the monthly cost attached to it is buying something the architecture does not require.

This is the same reasoning as polling rather than using webhooks: choosing the direction the connection runs decides most of what the system costs and most of how it fails.


We build Shopify automation that runs on the client's own hardware: no hosting, no domain, no monthly fee, with a local admin panel included. Fixed price, source code handed over on completion.

Quoted a monthly fee for something that runs in your own building? Book a free 30 minute call and we will tell you whether it needs one. Or see our app development work.

Frequently asked questions

Can a Shopify integration run without hosting?

Yes, if it only talks outward. A process that polls the Shopify API and acts locally needs no server, domain or public address — it makes outbound HTTPS calls that any firewall already allows. Hosting becomes necessary when something needs to reach in: a webhook, an embedded admin page, or an OAuth callback.

Does a custom Shopify app need a monthly fee?

Not inherently. The monthly fee in most quotes is hosting, and hosting is required only for inbound connections. A local, poll-based automation has no recurring cost beyond the machine it runs on, which usually already exists.

Do I need a domain for a Shopify custom app?

Only if Shopify or a browser needs to reach your code. Polling requires no domain, no DNS and no TLS certificate, because nothing is listening for incoming requests.

How do I configure an automation with no web interface?

It has one — served locally. The process runs a small admin panel on localhost or the local network with settings, logs, the queue and retry controls. A real interface, simply not on the public internet.

What are the downsides of running automation locally?

One machine is one point of failure, monitoring and backups are your responsibility, and updates are manual. The important one is monitoring: build a heartbeat and alert on the absence of a successful run, because a stopped process looks exactly like a quiet day.

Does a custom Shopify app need maintenance?

Yes, a few hours a year. Shopify ships two API versions annually with a published deprecation schedule, so expect to review a custom integration roughly once a year. Anyone promising zero maintenance forever is describing something that will break quietly.

When does a Shopify automation actually need a server?

When staff need a screen inside the Shopify admin, when the app is distributed through the App Store, when a customer's browser touches it during a purchase, when sub-second reaction matters, or when multiple locations share state.

A

About the author

Ashraful

Shopify Select Partner, Top Rated Plus on Upwork. 700+ Shopify projects shipped over 7+ years: themes, apps, migrations, speed, Hydrogen. Solo shop, no agency middlemen.

Read the full story

Working on a Shopify project?

That's what I do every day. Pick whichever feels lower-friction.