Skip to main content
Altcraft Docs LogoAltcraft Docs Logo
User guide iconUser guide
Developer guide iconDeveloper guide
Admin guide iconAdmin guide
English
  • Русский
  • English
Login
    Getting StartedAdministrator documentationFunctional characteristics
      Technology descriptionarrow
    • Architecture OverviewComponent Description
        Deployment schemesarrow
      • Basic schemeFail-safe schemeTypical Placement in Infrastructure
    System requirements
      Admin Panelarrow
      • Account areaarrow
        • Accountsarrow
        • Account UsersAccount Virtual SendersAccount Database Indexes
        TariffsExternal data configurationLDAPTasksSchedule JobsGlobal Stop ListsWebversion Store Policies
        Settingsarrow
      • Databases
          Accessarrow
        • AdminsAPI tokens
        Notifiers
          MTAarrow
        • Default rulesRetry rulesLock rulesBounce patternsStrategiesKeysISPsPools
      Nodes
        Sendersarrow
      • EmailSMSEvent generatorIntegration with SendsayENS: настройка сендера
        Reportsarrow
      • Audit JournalData Usage
        Toolsarrow
      • ARF decoderURL decoderSMID decoderLicense
      Platform installationarrow
    • Automatic installationManual installationRunning the platform in a Docker container
      Platform configurationarrow
    • Configuration fileDomain settingsLDAP access configurationSending Email via SMTP relayPixel and push domain configurationCluster and Replication SetupSystem notifications configurationProcesses UNIX sockets configurationHTTPS ConfigurationMigrating from MongoDB Community Edition to Percona Server for MongoDBAdding sender IP addressesDeduplication request settingsPostgreSQL database for account dataProxy server settingsKeycloak Integration with AltcraftGetting HTTP service statusesConfiguration MongoDB logs rotation
        Configuration of system constants and directoriesarrow
      • Filtering bot actionsDirectory of gender markers
      Platform maintenancearrow
    • Personnel requirementsPlatform maintenance processesPlatform updatingPlatform service monitoringBackup and recoveryTransferring the platform to a new serverCreating, deleting, and populating tables for statistics in ClickHouseUsage of the aktool utilityUsers and directories engaged by the platform
      Custom channels guidearrow
    • OverviewCreating and configuring a channelEntity field configurationTemplate languageEntities
        Pipesarrow
      • Pipe: Basic ConceptsResultErrorsLogPackUnpackHTTP RequestStore SetStore GetSelectorSQLEventerScheduler
        Pipelinesarrow
      • Pipeline: Basic ConceptsMessageScheduleListenerModerateStop
      Extraarrow
    • System page customizationSend Message IDИнструкция по миграции истории в ClickHouseInstructions for migrating history to ClickHouseUtility for importing push subscriptions to Firebase projectUtility for importing push subscriptions to Firebase project
    Processing HTTP/HTTPS traffic
      Administrator APIarrow
      • Accounts admin apiarrow
        • Restricted accessarrow
        • Account Activation and DeactivationAccount Freeze and Unfreeze
        Get accounts listAdd a new accountDelete the account
        Account usersarrow
      • Update an Existing AccountAdd a new accountDelete a userGet a list of usersSending a Welcome Email
        Nodesarrow
      • Synchronize node MTA configurationGet nodes listGet node MTA statusActivate node MTADeactivate node MTA
        Senders admin apiarrow
      • Create or update AKMTA senderGet AKMTA sender informationAssign account to senderGet senders listDelete senderRestore sender
          Sender queuearrow
        • Get sender queue informationHold sender queueRelease sender queueClear sender queue
        Virtual sendersarrow
      • Get virtual senders listGet virtual sender informationCreate virtual senderUpdate virtual senderClone virtual senderDelete virtual sender
    Documentation Archive
  • Technology description
  • Deployment schemes
  • Typical Placement in Infrastructure

Typical Placement in Infrastructure

Description​

Depending on the tasks and operational requirements, Altcraft can be deployed in different ways. This page presents several simplified and most common deployment schemes in a customer’s infrastructure. These diagrams are intended for general reference and help to understand the basic principles of system design, on the basis of which a specific architecture is then formed according to project requirements. Key components in the diagrams:

  • Control server — server(s) hosting Altcraft services and databases.
  • Sending server — server(s) hosting the akmtad and node services, which are part of Altcraft.
  • MTA (Mail/Message Transfer Agent) — the akmtad mail agent included in Altcraft, responsible for email delivery.
  • Web resources — the customer’s or partners’ web resources where visitor tracking is performed.
  • Users — system users: administrators, marketers, designers, etc.
  • Applications — external or internal customer services that interact with Altcraft.
  • Cloud messaging — cloud services for sending PUSH notifications (Google Firebase, Apple APNs, etc.).
  • Subscribers — end users: buyers, subscribers, website visitors. In Altcraft they are tracked as profiles.
  • Email services (ISP) — email providers (e.g., Gmail, Yandex, etc.) that receive email messages.

Regardless of the deployment method, the following questions must be addressed in advance:

  • Which domain will be used for the control panel?
  • Which domain will be used for tracking, pixel?
  • Which domains will be used for From and MAIL FROM in email mailings?

Without Load Balancing​

This scheme is suitable for the following cases:

  • test or pilot deployment;
  • deployment in external networks;
  • implementation in small organizations;
  • working with relatively small volumes of email mailings.

Deployment scheme

If necessary, access to the control panel and API can be restricted to the internal network. A distinctive feature of this scheme is SSL termination handled by Altcraft itself — the certificate is placed inside the service.

info

At the moment, Altcraft runs three separate Nginx instances, which requires three IP addresses on the server. Otherwise, launching on the same ports will cause conflicts.

The MTA interacts with ISPs directly, which allows the use of bypass mechanisms (various retry rules for automatic resending).

info

At least two IP addresses are required for sending. Depending on mailing volume and content type, more addresses may be needed to increase delivery speed and improve deliverability.

Using an SMTP Relay​

This scheme is suitable for the following cases:

  • test or pilot deployment;
  • deployment in external networks;
  • implementation in small organizations;
  • working with relatively small volumes of email mailings;
  • need to use an SMTP relay.

When using an SMTP relay, the Altcraft MTA must receive delivery reports (DSN, Delivery Status Notification). Such a report may be generated either by the relay itself or by the destination email service. The key requirement is that the domain in MAIL FROM (Return-Path header) must point to one of the IP addresses configured in the Altcraft sender (or the domain must resolve to the relay only for external servers — this can be achieved with Split DNS; in that case, the relay must forward received messages to the MTA). Upon receiving a report, Altcraft automatically processes it and records a delivery or non-delivery event.

Deployment scheme

With Load Balancing​

This scheme is suitable for the following cases:

  • implementation in large organizations;
  • deployment in external or private networks;
  • planned clustering;
  • working with relatively large volumes of email mailings.

In this case, Altcraft can operate in a private network, while message delivery and HTTP interaction are handled by the customer’s infrastructure.

info

All databases can be replicated, thereby improving the overall fault tolerance of the solution.

info

The load balancer must pass the client’s real address in the X-Real-IP or X-Forwarded-For header, and its IP address must be listed as trusted in the Altcraft configuration.

Other Options​

For example, to ensure high-performance sending (millions of emails per hour), multiple MTA servers can be deployed.

info

If a server has multiple IP addresses, one of them can be used for sending via an SMTP relay by creating a dedicated sender.

And to simplify maintenance, all databases can be moved to a dedicated server and resources redistributed.

The specific scheme depends on the tasks at hand — for example, a prioritized delivery channel. Details of the optimal configuration can be clarified with the Altcraft team: team@altcraft.com.

Last updated on Mar 12, 2026
Previous
Fail-safe scheme
Next
System requirements
  • Description
  • Without Load Balancing
  • Using an SMTP Relay
  • With Load Balancing
  • Other Options
© 2015 - 2026 Altcraft, LLC. All rights reserved.