Loading tutorials…
Loading tutorials…
Magento is the most powerful e-commerce platform you can run — and the easiest to misconfigure on day one. Most DIY installs skip Elasticsearch, run on shared hosting, and ship with /admin still publicly addressable. Here's the install path that won't haunt you in month three.
Who this is forFounders or operators standing up a fresh Adobe Commerce / Magento 2.4.x store. Either you've decided Magento over Shopify because of catalog complexity, B2B needs, or multi-store requirements — or you've inherited a Magento install and want to know whether it's set up correctly.
What you'll need
Step 1
Magento 2.4.x will technically install on 2 GB RAM but will not run a real store. Plan for 4-8 GB RAM, dedicated services, and SSD storage.
Choose a host that gives you root SSH and lets you install services. Good fits: a managed Magento host (Cloudways Pro plans, Magento-specialized hosts like Nexcess or Sonassi), a Magento-Cloud subscription if you have Adobe Commerce licensing, or a self-managed VPS on Hetzner / DigitalOcean / Linode with at least 4 GB RAM.
Verify PHP 8.2 or 8.3 is available — Magento 2.4.7+ requires it. Earlier 7.4 paths are dead.
Install or enable: MariaDB 10.6+ (or MySQL 8.0+), Elasticsearch 7.17 (or OpenSearch 2.x), Redis 6+ (used for sessions + cache), Varnish 7+ (full-page cache). All four are non-optional in a production-grade Magento stack.
Increase PHP limits: memory_limit = 2G, max_execution_time = 1800, realpath_cache_size = 10M, realpath_cache_ttl = 7200, opcache.memory_consumption = 512. These are the minimums Adobe's own docs ask for and nearly every shared host falls short.
Confirm with `php -v`, `composer --version`, `curl -X GET 'localhost:9200'` (Elasticsearch), `redis-cli ping`. If any of these fail, fix at the OS level before continuing.
Step 2
Use Composer with your Adobe Commerce keys. The zip path is older, doesn't get patches cleanly, and breaks on the first composer update.
Log into your Magento Marketplace account → My Profile → Access Keys. Generate a public + private key pair if you do not have one. These authenticate Composer against repo.magento.com.
On the server, in /var/www/ (or wherever your web root lives): `composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.4.7 magento2`. Use `magento/project-enterprise-edition` if you have an Adobe Commerce (paid) license.
When prompted, paste the public key as username and private key as password. Composer will pull the full Magento codebase. This step takes 5-15 minutes.
Set filesystem permissions: `find var generated vendor pub/static pub/media app/etc -type f -exec chmod g+w {} +` and `find var generated vendor pub/static pub/media app/etc -type d -exec chmod g+ws {} +`. The web-server user must own these directories.
Run the installer: `bin/magento setup:install --base-url=https://your-domain/ --db-host=localhost --db-name=magento --db-user=magento --db-password=... --admin-firstname=... --admin-lastname=... --admin-email=... --admin-user=... --admin-password=... --language=en_US --currency=USD --timezone=America/New_York --use-rewrites=1 --search-engine=elasticsearch7 --elasticsearch-host=localhost --elasticsearch-port=9200`.
Install completes in 3-8 minutes. Save the admin URL the installer prints — it includes a random suffix (e.g., /admin_a1b2c3) for security. Bookmark it now.
Step 3
Out of the box, Magento writes sessions and cache to disk — fine for dev, fatal for production. Wire Redis for both, plus Varnish as the FPC backend.
Sessions to Redis: edit `app/etc/env.php` → add `session` config block pointing to Redis on db=2. This eliminates filesystem session locking, which is the #1 cause of "checkout hangs" on busy Magento stores.
Default cache to Redis (db=0) and full-page cache to Redis (db=1). The cache block in env.php should reference `Magento\Framework\Cache\Backend\Redis` for both `default` and `page_cache`.
Configure Varnish as the storefront-facing cache: `bin/magento setup:config:set --http-cache-hosts=127.0.0.1:6081 && bin/magento config:set system/full_page_cache/caching_application 2`. Then generate the Varnish VCL via `bin/magento varnish:vcl:generate` and load it.
Run `bin/magento cache:flush` and `bin/magento setup:upgrade` once everything is wired. Reload your storefront and check response headers — you should see `X-Magento-Cache-Debug: HIT` after the second pageview.
Without this, your TTFB will be 1500-3000ms even on a fast server. With it, expect 80-200ms on cached pages.
Step 4
Magento admin is the highest-value attack surface in the entire codebase. Harden before launch, not after the first compromise.
Enable admin 2FA: `bin/magento module:enable Magento_TwoFactorAuth` (already enabled by default on 2.4.x) → Stores → Configuration → Security → 2FA → select Google Authenticator or U2F. Every admin user must enroll on next login.
Restrict admin by IP at the web-server layer (nginx `allow/deny` or Apache `Require ip`). If your team is remote, allow office IPs + require VPN for everyone else. Public /admin even with 2FA is needless exposure.
Set a strong admin URL suffix (already done by installer) AND a frontname change if compliance requires: `bin/magento setup:config:set --backend-frontname=admin_xxx`.
Disable directory indexing: confirm `Options -Indexes` is set in .htaccess (Apache) or `autoindex off` in nginx. Critical — without it, /pub/media/wysiwyg/ becomes a public file browser.
Force HTTPS site-wide: Stores → Configuration → Web → Base URLs (Secure) → "Use Secure URLs on Storefront" = Yes, "Use Secure URLs in Admin" = Yes, "HTTP Strict Transport Security (HSTS)" = Yes.
Install the official `magento/security-package` if not already present. Run `bin/magento security:recaptcha:settings` to wire reCAPTCHA into login, contact form, and checkout.
Step 5
Locale, currency, store name, contact info, tax class defaults — set these BEFORE you import products. Changes after products exist trigger expensive reindexing.
Stores → Configuration → General → General → Country Options: set default country, allowed countries (only the ones you ship to), top destinations. Restricting to actual ship-to countries cuts checkout abandonment from non-fulfillable orders.
Stores → Configuration → General → Currency Setup: enable allowed currencies, set default. If multi-currency, set up the currency import service (Yahoo Finance is deprecated — use Fixer.io or Open Exchange Rates).
Stores → Configuration → General → Store Information: legal business name, phone, hours, address, VAT/Tax ID (if EU). This populates invoices, transactional emails, and structured data.
Stores → Configuration → Sales → Tax: pick default Tax Origin (where you ship from), Tax Calculation Method (Unit Price for US, Total for EU VAT), and whether catalog prices include tax (US: No, EU: Yes).
Stores → Configuration → Catalog → Inventory: set "Display Out of Stock Products" = No (default) to avoid SEO indexing dead SKUs.
Save. Run `bin/magento cache:flush` after each config block. Storefront configuration is cached aggressively and stale settings will fight you all afternoon.
Step 6
Magento's built-in SMTP layer is fragile. Install the Mageplaza SMTP module or use an authenticated transactional provider (SendGrid, Postmark, AWS SES).
Install an SMTP extension: `composer require mageplaza/module-smtp` (free, MIT-licensed) or use Adobe Commerce's built-in `Magento_Email` with custom SMTP configured in env.php.
Pick a transactional provider: Postmark (best deliverability for small stores), SendGrid (most common), or AWS SES (cheapest at scale, requires DKIM/DMARC setup).
Configure SMTP: hostname, port (587 for TLS, 465 for SSL), authentication (always required — never run unauthenticated relay), and the from-email matching a verified sender domain.
Set up SPF, DKIM, and DMARC for your sending domain. Without all three, Gmail will route your order confirmations to spam within a week of launch.
Send a test email from Stores → Configuration → Advanced → System → Mail Sending Settings → 'Send Test Email.' Confirm it arrives in inbox (not spam) with all three auth records passing.
Test the actual transactional templates: place a $0.01 test order with Stripe in test mode → confirm order confirmation, shipment, and invoice emails all deliver.
Step 7
Without cron, indexers do not run, search does not refresh, customer emails do not send, and the admin throws nag banners. Set it once, monitor forever.
As the web-server user (typically www-data or magento), edit crontab: `crontab -u www-data -e`.
Add the three required entries from `vendor/bin/magento cron:install` output, or paste manually: `* * * * * /usr/bin/php /var/www/magento2/bin/magento cron:run 2>&1 | grep -v 'Ran jobs by schedule' >> /var/www/magento2/var/log/magento.cron.log`. Repeat for `update/cron.php` and `setup/cron.php`.
Verify cron is running: `tail -f /var/www/magento2/var/log/magento.cron.log` — you should see job runs every minute.
Check the admin: System → Tools → Cache Management → 'cron.lock' should not be present after 5 minutes. If it persists, cron has hung — usually due to a stuck consumer or filesystem permission issue.
Set up an external uptime check (UptimeRobot, Hyperping) on a small page that confirms cron health (e.g., a custom controller that exposes `last cron run` timestamp). Cron silently dying is the most common production Magento failure.
Common mistakes
Installing on shared cPanel hosting
What goes wrong: Magento 2.4.x requires Elasticsearch and Redis. Shared cPanel hosts almost never provide these. You will hit installer errors and be unable to launch — or you will install on a hacked PHP version and end up with a fragile store that crashes weekly.
How to avoid: Move to a VPS, managed Magento host (Nexcess, Cloudways Magento plan), or Adobe Magento Cloud. Budget $40-150/mo for hosting.
Running developer mode in production
What goes wrong: Verbose error pages leak code paths, stack traces, and database schema details to attackers. Compiled code generation is disabled — every page request pays a 200-500ms penalty. Cache layers are partially bypassed.
How to avoid: Run `bin/magento deploy:mode:set production`. Confirm with `bin/magento deploy:mode:show`. Re-run after every deployment.
Skipping Redis for sessions
What goes wrong: Filesystem sessions create per-user file locks. Two concurrent requests from the same browser (image lazy-load + AJAX cart) wait for each other. Checkout silently hangs. Customers blame "your slow site."
How to avoid: Configure Redis sessions in env.php (db=2). Validate with `redis-cli -n 2 KEYS "*"` — sessions should appear there, not in var/session/.
No cron configured (or cron running as wrong user)
What goes wrong: Indexers stop updating, search results go stale, emails queue but never send, admin shows persistent yellow banners. Site appears to 'work' but every backend process silently stalls. Most discovered weeks later when customers report missing order confirmations.
How to avoid: Install cron as the web-server user (NOT root). Verify with `tail -f var/log/magento.cron.log`. Set up an external uptime check on cron health.
Public /admin URL with no IP restriction
What goes wrong: Bots brute-force the admin login 24/7. Even with 2FA enabled, login throttling slows the admin to a crawl during attacks. Logs fill up with thousands of failed attempts.
How to avoid: Keep the random admin URL suffix from installer. Add web-server-level IP allowlist (nginx allow/deny or Cloudflare Access). Force VPN for remote admin users.
Default email config (no SPF/DKIM/DMARC)
What goes wrong: Order confirmations route to spam, shipment emails never arrive, customers email support asking 'did my order go through?' Trust collapses. Refund/return rate spikes 2-4x.
How to avoid: Use a real transactional provider (Postmark, SendGrid, SES). Add SPF + DKIM + DMARC records to DNS. Send a test through mail-tester.com — score should be 9/10 or higher before launching.
Misconfigured Elasticsearch / OpenSearch
What goes wrong: Catalog search returns zero results or stale data. "I searched for the product I literally just published and it is not there" is the most common new-Magento-operator complaint. Reindexing seems to fix it, then breaks again.
How to avoid: Match Magento version to the right ES/OS version (Magento 2.4.7 → Elasticsearch 7.17 or OpenSearch 2.x). Run `bin/magento indexer:reindex catalogsearch_fulltext`. Schedule daily reindex via cron job, not the default "Update on Save."
Recap
Done — what's next
How to set up a Magento product catalog correctly
Read the next tutorial
Hand it off
Setting up Magento correctly takes 8-12 hours if you know the platform, 2-3 days if you don't. The mistakes you make in the first week compound for 6-12 months. A vetted Magento specialist can install, harden, and validate a production-ready Adobe Commerce store in 3-5 days at $14-16/hr part-time — typically $1,200-2,000 total for setup, $400-800/mo for ongoing maintenance.
See specialist rates
Magento Open Source (free, community-supported) covers 80% of stores under $5M annual revenue. Adobe Commerce (paid, $22K/yr starting) adds B2B features, advanced segmentation, content staging, and Adobe support. If you do not know which you need, start with Open Source — you can upgrade later. The codebase is the same; Adobe Commerce is Open Source + commercial modules.
No. Magento 2.4.x requires Elasticsearch or OpenSearch, which almost no shared host provides. You also need Redis and ideally Varnish. Realistic minimum: a $20-40/mo VPS, or a managed Magento host at $40-150/mo. Trying to install on $5/mo cPanel hosting is the most common 'why is my store broken' story we see.
Magento 2.4.7 is the self-hosted release you install on your own server. Adobe Commerce on Cloud is a managed PaaS — Adobe runs the infrastructure, deploys via Git, includes Fastly (Varnish), New Relic, and Blackfire. Cloud starts around $40K/yr; self-hosted Magento Open Source is free + hosting costs ($40-300/mo).
If your hosting prereqs are clean (PHP 8.2, MariaDB, Elasticsearch, Redis already running): 2-3 hours for the core install + 4-6 hours for hardening + base config. If you are also setting up hosting from scratch, double that. Plan a weekend, not an afternoon.
For initial setup and security patches: yes, you need someone comfortable with SSH and Composer. For day-to-day catalog management and content updates, the admin UI is usable by non-devs. The middle ground (occasional extension updates, monthly patching) is where most operators get burned trying to DIY — that's the right place for a part-time Magento specialist.
Use Shopify if you sell under 1,000 SKUs, have under $5M revenue, and want zero infrastructure work. Use Magento if you have 10K+ SKUs, complex pricing rules, B2B accounts with negotiated pricing, multi-store / multi-brand requirements, or need full code-level control. Most stores under $10M/yr are better off on Shopify. Stores at $10M+ with catalog complexity are usually better on Magento.
Adobe Commerce
The Magento catalog is the most powerful — and most easily mismanaged — part of the platform. Most stores ship with attributes used once, sets that nobody understands, and categories indexed into oblivion. Here's the catalog architecture that scales past 10,000 SKUs without grinding to a halt.
Adobe Commerce
Out-of-the-box Magento ships Google Analytics with the legacy Universal Analytics integration — which Google killed in 2023. If your store is reporting traffic but no purchases (or purchases with no items array), you've inherited the broken setup. Here's the correct GA4 + GTM + Enhanced Ecommerce stack.
Shopify
DIY Shopify marketing is a great idea — until it isn't. This is the honest framework: when the cost of self-managing exceeds the cost of hiring, and how to tell which side you're on.